• human-readable nodelist format

    From andrew clarke@3:633/285.4 to All on Fri Nov 1 03:44:44 2002
    Document: nodelist.txt
    Revision: 001
    Date: 2002-11-01

    Human-readable (HR) distribution nodelist
    November 1, 2002
    andrew clarke
    3:633/285.4@fidonet
    mail@ozzmosis.com


    Status of this document
    -----------------------

    This document is a FidoNet Standards Proposal (FSP).

    This document specifies an optional FidoNet standard protocol for
    the FidoNet community, and requests discussion and suggestions for
    improvements.

    This document is released to the public domain, and may be used,
    copied or modified for any purpose whatever.


    Rationale
    ---------

    With the advent of Internet-capable FidoNet nodes, the FTS-0005 nodelist
    format has now been rendered woefully inadequate to describe all the mail-delivery capabilities of each node. This document aims to describe
    an attempt to design a new nodelist format to rectify this situation
    with the aim of being able to translate back to FTS-5 format without difficulty.


    Human-readable (HR) nodelist format
    -----------------------------------

    For simplicity and ease of use a human-readable (HR) ASCII text file
    format was chosen (in preference to, for example, CSV [Comma Separated
    Values] or XML [eXtensible Markup Language] formats). Of course this
    does not rule out the use of (or conversion to) these formats for future distribution of the FidoNet nodelist or segments thereof.


    Lines
    -----

    Lines in the HR nodelist are separated by a single newline character
    (ASCII 10). Blank (empty) lines are permitted.


    Comments
    --------

    All comments in the HR nodelist must begin with either a semicolon (;)
    or hash/hatch (#) characters in the first column of a line of text. The nodelist comment ends at the first newline character.


    Keywords
    --------

    Keywords in the HR nodelist must begin in the first column of a line of
    text. If a keyword has a [data] portion, a space (ASCII 32) should be
    placed between the keyword and the data. Keywords are case neutral, ie.
    they may be all uppercase, all lowercase, or a mixture of the two.

    The following keywords are proposed:

    Domain [domain]

    Defines the FTN domain, [domain], that the nodelist applies
    to. This should be specified before any of the keywords below.

    Address [address]

    The [address] (in zone:net/node format) following the Address
    keyword defines the address of a node in the nodelist. Point
    addresses are not permitted. Each time an Address line appears in
    the HR nodelist, the information that follows it applies to that
    node only. Multiple Address keywords for the same node are
    permitted to describe nodes with multiple mail delivery methods
    with differing online times (refer to the Online keyword below).

    Status [type]

    The Status keyword defines the status "type" of a node. If no
    Status keyword is present the node is a normal node entry. The
    following status types may be used:

    Zone

    Defines a geographic zone and its coordinator.

    Region

    Defines a geographic region and its coordinator.

    Host

    Defines a local network and its host.

    Net

    The "Net" type is a synonym for "Host".

    Hub

    Defines of a routing sub-unit within a multilevel local
    network. The hub is the routing focal point for its
    child nodes.

    Private

    Defines a private node.

    Pvt

    The "Pvt" type is a synonym for "Private".

    Hold

    Defines a node which is temporarily down. Mail may be
    sent to its parent node and held there.

    Down

    Defines a node which is inoperational. Mail may not be
    sent to it. This keyword may not be used for longer than
    two weeks on any single node, at which point the "down"
    node is to be removed from the nodelist.

    Parent [address]

    The [address] (in zone:net/node format) following the Parent
    keyword defines the parent (or uplink) of a node. For Zone
    listings, no Parent keyword is allowed. For all other purposes it
    is mandatory.

    Uplink

    The "Uplink" keyword is a synonym for "Parent".

    Name [text]

    The [text] following the Name keyword contains the name by which a
    node is commonly known. This text may contain any alphanumeric or
    punctuation characters other than commas or underscores.

    Location [text]

    The [text] following the Location keyword contains the
    geographical location of a node. It is usually expressed as the
    primary local location (town, suburb, city, etc.) plus the
    identifier of the regional geopolitical administrative district
    (state, province, department, county, etc.). Wherever possible,
    standard postal abbreviations for the major regional district
    should be used (IL, BC, NSW, etc.). This text may contain any
    alphanumeric or punctuation characters other than commas or
    underscores.

    Operator [text]

    The [text] following the Operator keyword contains the name of
    the primary system operator of the node.

    SysOp [text]

    The "SysOp" keyword is a synonym for "Operator".

    Operating [text]

    The [text] following the Operating keyword describes the transport
    method, protocol and any other information required to contact the
    node using that delivery method and protocol. Multiple Operating
    keywords for the same node are permitted to allow more than one
    delivery method to be described.

    For nodes contactable via dialup modem, the following format is
    used:

    Operating [Dialup] [FTS-1] [at] [phonenumber][,flags]

    Where [Dialup] is "Dialup" or "Dial-up", case neutral.

    Where [FTS-1] is "FTS-1" or "FTS1", case neutral.

    Where [at] is the word "at", and is case neutral and
    superfluous.

    Where [phonenumber] is in the format described by FTS-0005
    (or a superseding document).

    Where [,flags] is a comma-separated list of nodelist flags
    in the format described by FTS-0005 (or a superseding
    document).

    For nodes contactable via TCP/IP using the Binkp protocol,
    the following format is used:

    Operating [TCP/IP] [Binkp] [at] [host]

    Where [TCP/IP] is "TCP/IP" or "TCPIP" or "TCP" or "IP",
    case neutral.

    Where [Binkp] is "Binkp", case neutral.

    Where [at] is the word "at", and is case neutral and
    superfluous.

    Where [host] specifies the fully-qualified hostname or IP
    address of the node.

    Online [text]

    The [text] following the optional Online keyword lists the times
    that the node is online. The format of the [text] field is:

    [day] [start time]-[end time]

    Where [day] specifies the day of the week when the node is online,
    and is a three letter English abbreviation for the day of the week,
    ie. Sun, Mon, Tue, Wed, Thu, Fri or Sat. [day] is case neutral.

    Where [start time] specifies the time when a node begins operation.

    Where [end time] specifies the time when a node ends operation.

    Times must be specified in 24-hour HH:MM format in UTC, where HH is
    the hours elapsed since midnight and MM is the minutes elapsed in
    that hour. The hour and minute are to be expressed in decimal and
    must have a leading zero if their values are less than 10.

    Multiple Online keywords for the same node are permitted to allow
    multiple online times to be described.

    Contact [text]

    The [text] following the optional Contact keyword describes a method
    of contacting the operator of the node. Multiple Contact keywords
    for the same node are permitted to allow more than one contact
    method to be described for a node. Examples of Contact entries in
    the HR nodelist might be:

    Contact E-mail mail@ozzmosis.com
    Contact Fax +61-3-1234-5678


    References
    ----------

    [FTS-0001] "A Basic FidoNet(r) Technical Standard", Randy Bush.
    September 1995.

    [FTS-0005] "The Distribution Nodelist", Ben Baker, Rick Moore,
    David Nugent. February 1996.

    [FSP-1011] "Binkp - a protocol for transferring FidoNet mail over
    reliable connections", Dima Maloff, Nick Soveiko, Maxim Masiutin.
    July 2000.

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/285.4)
  • From andrew clarke@3:633/285.4 to All on Fri Nov 1 04:56:14 2002
    Fri 2002-11-01 03:44, andrew clarke (3:633/285.4) wrote to All:

    Human-readable (HR) distribution nodelist

    I'm not much of a documentation-writer, but I've tried to describe the format I'm proposing. If people think they can rewrite a paragraph here and there so it makes more sense, or some changes in the file format, do so and send me the changes.

    I'd like to avoid getting into an unproductive HR vs XML vs CSV argument though. At the end of the day the formats should be all translatable and interchangable anyway. And if you really want to have an XML (or some other format) nodelist, write a spec for it, and proof-of-concept code!

    I've hacked together some example proof-of-concept code to translate the FTS-5 nodelist to HR format, and the resultant file back to FTS-5 format (minus the original comments and CRC). It's public domain, written in C and is at

    http://blizzard.dnsalias.org/fidonet/nodelist/

    From there you can also download Win32 binaries and a copy of a sample HR format nodelist (a 400K zip file).

    Regards
    Andrew

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/285.4)
  • From Scott Little@3:712/848 to andrew clarke on Fri Nov 1 11:48:19 2002
    [ 01 Nov 02 03:44, andrew clarke wrote to All ]

    Operating [text]

    [snip]

    Online [text]

    There should be provision for online times to be specified as part of the Operating line as an override to the default Online time(s).


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From andrew clarke@3:633/285.4 to Scott Little on Fri Nov 1 16:34:34 2002
    Fri 2002-11-01 11:48, Scott Little (3:712/848) wrote to andrew clarke:

    Operating [text]

    [snip]

    Online [text]

    I forgot to mention in the document that if an Online keyword is not listed for
    a node then it is assumed to be operating continuously.

    There should be provision for online times to be specified as part of
    the Operating line as an override to the default Online time(s).

    Like this?

    Address 1:234/567
    Operating Dialup FTS-1 at 61-1-1234-5678,XA Sat 00:00-06:00
    Operating TCP/IP Binkp at 127.0.0.1 Sun 00:00-06:00

    How would you express multiple days without the line getting too long? I wanted
    to avoid long lines of text, because it tends to defeat the human-readable aspect.

    This is not really any different to:

    Address 1:234/567
    Operating Dialup FTS-1 at 61-1-1234-5678,XA
    Online Sat 00:00-06:00

    Address 1:234/567
    Operating TCP/IP Binkp at 127.0.0.1
    Online Sun 00:00-06:00

    Which the spec allows.

    Regards
    Andrew

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/285.4)
  • From Scott Little@3:712/848 to andrew clarke on Fri Nov 1 21:32:41 2002
    [ 01 Nov 02 16:34, andrew clarke wrote to Scott Little ]

    This is not really any different to:
    Address 1:234/567
    Operating Dialup FTS-1 at 61-1-1234-5678,XA
    Online Sat 00:00-06:00
    Address 1:234/567
    Operating TCP/IP Binkp at 127.0.0.1
    Online Sun 00:00-06:00

    Fair nuff...

    keyword defines the address of a node in the nodelist. Point
    addresses are not permitted. Each time an Address line appears in

    Why no point addresses allowed? The offical Fidonet nodelist won't include points, but the spec should allow them otherwise yet another format will be required for points.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From andrew clarke@3:633/267 to Scott Little on Sat Nov 2 05:55:36 2002
    Fri 2002-11-01 21:32, Scott Little (3:712/848) wrote to andrew clarke:

    keyword defines the address of a node in the nodelist. Point
    addresses are not permitted. Each time an Address line appears in

    Why no point addresses allowed? The offical Fidonet nodelist won't
    include points, but the spec should allow them otherwise yet another
    format will be required for points.

    Someone sent me a copy of the Z2/Z6 pointlist just after I wrote that. It's 7Mb! Even if a quarter of the people in it are actually real people then they're probably worth catering for. ;-)

    I couldn't think of a rationale for including them at the time. After reading the spec for the pointlist format documented in FTS-5002, I see it suffers from
    the same inadequecies of the FTS-5 nodelist, ie. fields 3 to 8 of the Boss entry in the pointlist must be a copy of the same corresponding fields in the nodelist entry unless those fields are left out altogether, etc.

    Also, I'd forgotten about the "Point format" lists (documented in FTS-5002) entirely.

    Anyway, points will be allowed! I'll amend the spec soon. ;-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Scott Little@3:712/848 to andrew clarke on Sat Nov 2 09:47:45 2002
    [ 02 Nov 02 05:55, andrew clarke wrote to Scott Little ]

    fields 3 to 8 of the Boss entry in the pointlist must be a copy of the same corresponding fields in the nodelist entry unless those fields
    are left out altogether, etc.

    Speaking of which.. is it worth allowing dummy entries? ie. dummies for St. Louis style would be:

    zone,3
    region,54
    host,712
    ,848
    point,1,foo,bar,baz,-unpublished-,etc,etc,etc.

    This allows specifying (but not overriding existing) missing hierarchy* pieces that aren't part of the address (all of it for St. Louis, Domain and Region for
    HRN) without back-tracing.

    Of course dummy entries would only be valid for supplemental and maybe segment nodelists. Segment lists should also allow Origin and Password keywords (a bit
    of extra security)... or maybe some convention for private non-replicating keywords that is easily matched with wildcards (eg. x- or pvt-) and removed.

    *And on the subject of hierarchies..

    1) this format allows any node to be a Zone, Region, Net or Host, where traditionally they'd be Z:Z/0, Z:R/0 or Z:N/0. This would allow entries incompatible with the current scheme, therefore making backwards conversion impossible if someone were to create such an entry. The specs should include the proper addressing convention for such special node types, but stress this is current convention only and may change (ie. a note to lazy programmers who would normally just assume /0, to implement it properly).

    2) Is "uplink" the primary or alternate uplink, or both? Perhaps this keyword should change to "peers" and then list the systems it peers with (that allow public relaying from it), either in order of preference or with a numerical preference (ala DNS MX records).

    This would make mapping the ideal route to a node easier, and allow Zones to specify who they connect with. Also, a node's Hub, Host or Region (RINs) is automatically implied at lowest priority, if not specifically listed otherwise.

    There should be no technical limit to the number of peers allowed, but all software should be capable of correctly parsing the list to be considered compliant (ie. if they are numerically ordered, the software should read the entire list and accept the X most top ranked; if they are order dependant, the first X are accepted and the rest ignored rather than overwriting the previous).

    The maximum peers permitted in a nodelist would be determined by the *C's. Ideally, segment processors would be able to strip excess peers before sending to an uplink, allowing more peers for smaller segments (net, region or zone), and fewer for the the large ones (some of the big euronets and the international list).

    <end brainstorm session>
    <makes note to switch to decaf>


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sat Nov 2 10:08:06 2002
    [ 02 Nov 02 09:47, Scott Little wrote to andrew clarke ]

    <end brainstorm session>
    <makes note to switch to decaf>

    While we're at it, can we standardise the Flags formatting too (FTS-5001)? Eg.
    rather than Txx T:xx, making it simpler to parse them generically.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 3 03:05:39 2002
    [ 02 Nov 02 09:47, Scott Little wrote to andrew clarke ]

    This allows specifying (but not overriding existing) missing
    hierarchy* pieces that aren't part of the address (all of it for St.

    Actually... <anal retentive mode = on> this format allows any node to be placed
    out of order, since it mixes order-dependant information (domains, regions) with back referencing information (end nodes specify their zones and nets).

    FRL-1002.001 documents a full hierarchial address format, intended for route lists:

    DD:ZZ:RR:NN:HH:FF:PP

    which would look something like:

    fidonet:3:54:712:61:848:0

    Which isn't terribly readable since we're all used to Z:N/F, but it's easier to
    read by machine, which is what the nodelist is normally used for. If Z:F/N addresses are really necessary (for easier human text searching) it can be listed next to it, but ignored by machines.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to Scott Little on Sun Nov 3 03:23:05 2002
    [ 03 Nov 02 03:05, Scott Little wrote to andrew clarke ]

    (domains, regions) with back referencing information (end nodes
    specify their zones and nets).

    Unless "parent" is intended for 'host routing' not 'echomail routing' that is..


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Sat Nov 2 07:35:35 2002
    Hi andrew.

    01-Nov-02 04:56:14, andrew clarke wrote to All


    Fri 2002-11-01 03:44, andrew clarke (3:633/285.4) wrote to All:

    >> Human-readable (HR) distribution nodelist

    I'm not much of a documentation-writer, but I've tried to describe
    the format I'm proposing. If people think they can rewrite a
    paragraph here and there so it makes more sense, or some changes
    in the file format, do so and send me the changes.

    did you see what I was proposing a few months back.

    Mainly leting a node have multiple addresses (since many do) and thus
    saving repeating the same node with the same connection info and thus make
    the nodelist easier to maintain?

    also a way is needed to translate thesenew lists to old-style (possibly by reformatting and selectively dropping information) for se with existing software...



    Bye <=-

    ---
    * Origin: Line Printer paper is strongest at the perforations. (3:640/531.42)
  • From andrew clarke@3:633/267 to Scott Little on Tue Nov 5 10:31:00 2002
    Sat 2002-11-02 09:47, Scott Little (3:712/848) wrote to andrew clarke:

    fields 3 to 8 of the Boss entry in the pointlist must be a copy of
    the same corresponding fields in the nodelist entry unless those
    fields are left out altogether, etc.

    Speaking of which.. is it worth allowing dummy entries? ie. dummies
    for St. Louis style would be:

    zone,3
    region,54
    host,712
    ,848
    point,1,foo,bar,baz,-unpublished-,etc,etc,etc.

    This allows specifying (but not overriding existing) missing hierarchy* pieces that aren't part of the address (all of it for St. Louis, Domain
    and Region for HRN) without back-tracing.

    Well, the spec just defines a way to list nodes. The hierachy is only important when it comes down to default mail routing, and politics. Parsing software should be able to handle undefined nodes referenced by other nodes without failing (and maybe just print a warning message) unless this is unavoidable.

    Of course dummy entries would only be valid for supplemental and maybe segment nodelists. Segment lists should also allow Origin and Password keywords (a bit of extra security)... or maybe some convention for
    private non-replicating keywords that is easily matched with wildcards
    (eg. x- or pvt-) and removed.

    Probably a good idea. I think nodelist segments (and diffs) should probably be
    the subject of another document though, where the Origin and Password keywords can be described in terms of segment processing software and not in terms of the entire nodelist, because it would make no sense there, although maybe the Origin keyword would, I'm not sure.

    The actual process of merging HRN segments isn't something I've given a great deal of thought yet, because I don't know enough about what goes on now to propose what should happen in future. I do think a diff format that is standard (like GNU diff/patch) should be used rather than the obscure format used with nodediffs now. And of course, get rid of the vastly obsolete CRC in the new format nodelist altogether.

    *And on the subject of hierarchies..

    1) this format allows any node to be a Zone, Region, Net or Host, where traditionally they'd be Z:Z/0, Z:R/0 or Z:N/0. This would allow
    entries incompatible with the current scheme, therefore making
    backwards conversion impossible if someone were to create such an
    entry.

    True.

    The specs should include the proper addressing convention for
    such special node types, but stress this is current convention only and
    may change (ie. a note to lazy programmers who would normally just
    assume /0, to implement it properly).

    I'll add the proper addressing convention in. I'm not sure about the "may change" part though. It will never change until people stop using FTS-5 nodelists outright for a start. Then there is still the human problem (?) of people without a nodelist assuming that for eg. if they send mail to 3:3/0 they
    will get the Z3C. But yes, if the HRN happens to have an entry like:

    Address 3:666/666
    Status Zone

    Then there should probably be no reason why this can't be allowed in principle,
    but that HRN parsers should probably print a really big agressive warning saying that it's not backwards compatible with FTS-5 and that you'll go blind if you keep doing that.

    2) Is "uplink" the primary or alternate uplink, or both? Perhaps this keyword should change to "peers" and then list the systems it peers
    with (that allow public relaying from it), either in order of
    preference or with a numerical preference (ala DNS MX records).

    This would make mapping the ideal route to a node easier, and allow
    Zones to specify who they connect with. Also, a node's Hub, Host or
    Region (RINs) is automatically implied at lowest priority, if not specifically listed otherwise.

    ...

    Uplink is the primary uplink, ie. the parent of the node.

    Your idea (and somebody else mentioned something like this in FTSC_PUBLIC also)
    about listing non-default/ideal routing is fine technically but it may be difficult to get a consensus as to whether it's achievable if/when it comes to implementing it, and/or whether it's relevant in the basic nodelist at all. So
    it should probably be addressed in another document.

    And I should add to the current spec that "keywords in the nodelist that are not recognised should be ignored"!

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Tue Nov 5 11:20:48 2002
    Sat 2002-11-02 10:08, Scott Little (3:712/848) wrote to andrew clarke:

    While we're at it, can we standardise the Flags formatting too
    (FTS-5001)? Eg. rather than Txx T:xx, making it simpler to parse them generically.

    I couldn't find any ",T:" in my nodelist, so I think that's a non-issue, unless
    I've misunderstood.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Tue Nov 5 11:43:36 2002
    Sun 2002-11-03 03:05, Scott Little (3:712/848) wrote to andrew clarke:

    This allows specifying (but not overriding existing) missing
    hierarchy* pieces that aren't part of the address (all of it for St.

    Actually... <anal retentive mode = on> this format allows any node to
    be placed out of order, since it mixes order-dependant information (domains, regions) with back referencing information (end nodes specify their zones and nets).

    FRL-1002.001 documents a full hierarchial address format, intended for route lists:

    DD:ZZ:RR:NN:HH:FF:PP

    which would look something like:

    fidonet:3:54:712:61:848:0

    I think the addition of dummy entries to nodelist segments would satisfy any need to specify where a node was placed in the nodelist hierachy, if that was at all necessary, ie.

    Address 3:3/0
    Status Zone

    Address 3:54/0
    Parent 3:3/0
    Status Region

    Address 3:712/0
    Parent 3:54/0
    Status Host

    Address 3:712/61
    Parent 3:712/0
    Status Hub

    Address 3:712/848
    Parent 3:712/61
    Name sysgod.org
    Location Riverwood NSW
    Operator Scott Little

    Admittedly it is longer, but it IS human readable. :-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Jasen Betts on Tue Nov 5 11:55:58 2002
    Sat 2002-11-02 07:35, Jasen Betts (3:640/531.42) wrote to andrew clarke:

    Human-readable (HR) distribution nodelist

    I'm not much of a documentation-writer, but I've tried to describe
    the format I'm proposing. If people think they can rewrite a
    paragraph here and there so it makes more sense, or some changes
    in the file format, do so and send me the changes.

    did you see what I was proposing a few months back.

    I'm afraid I wasn't in FidoNet a few months back. I left in January 1999 and have only returned in the last couple of weeks. So if you want to repost your proposal, I'll have a look.

    Mainly leting a node have multiple addresses (since many do) and thus
    saving repeating the same node with the same connection info and thus
    make the nodelist easier to maintain?

    I don't see any reason why a single node shouldn't be able to have multiple connection methods listed in a new format nodelist. I don't see how the alternative could be easier to maintain. Sounds like it could only add more complexity to people's routing and system configs.

    also a way is needed to translate thesenew lists to old-style (possibly
    by reformatting and selectively dropping information) for se with
    existing software...

    The program I wrote, rnlcvt, does just that.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Scott Little@3:712/848 to andrew clarke on Tue Nov 5 17:54:52 2002
    [ 05 Nov 02 10:31, andrew clarke wrote to Scott Little ]

    The hierachy is only important when it comes down to default mail
    routing, and politics. Parsing software should be able to handle

    Thing is, this format requires at least two scans of the nodelist to find a node and it's uplink. The only shortcut is to assume an uplink of /0 for normal nodes.

    Probably a good idea. I think nodelist segments (and diffs) should probably be the subject of another document though

    St Louis segments are the same as the complete nodelist, only smaller, but they
    rely on static filenames to figure out who it's from and what it's for, which bothers me. If the nodelist contains it's origin, basic security, and any necessary dummy hierarchial information, that is no longer necessary.

    and Password keywords can be described in terms of segment processing software and not in terms of the entire nodelist, because it would

    It still needs to be standardised otherwise everyone will come up with their own method :)

    goes on now to propose what should happen in future. I do think a
    diff format that is standard (like GNU diff/patch) should be used
    rather than the obscure format used with nodediffs now.

    "diff" has a mode that is more or less identical to the current nodediff format

    I'll add the proper addressing convention in. I'm not sure about the
    "may change" part though. It will never change until people stop
    using FTS-5 nodelists outright for a start.

    You never know. Insufficient separation between Policy and Technical lead us to the Pvt,-unpublished- issue, for example.

    FTSC_PUBLIC also) about listing non-default/ideal routing is fine technically but it may be difficult to get a consensus as to whether
    it's achievable if/when it comes to implementing it

    It's no more difficult than back tracing "uplink" keywords until you bump into a node that I'm able to connect to.

    And I should add to the current spec that "keywords in the nodelist
    that are not recognised should be ignored"

    That will limit future developments, as old software will strip out new lines. The equivalent of all IP flags getting removed because an old processor was written before they exists. Best to pass on unknown keywords, the ZC's can determine what's valid in their zones and filter out the rest intelligently.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From andrew clarke@3:633/267 to Scott Little on Tue Nov 5 20:46:16 2002
    Tue 2002-11-05 17:54, Scott Little (3:712/848) wrote to andrew clarke:

    The hierachy is only important when it comes down to default mail
    routing, and politics. Parsing software should be able to handle

    Thing is, this format requires at least two scans of the nodelist to
    find a node and it's uplink. The only shortcut is to assume an uplink
    of /0 for normal nodes.

    Or one pass, then an in-memory search. I don't think this is a big problem.

    Probably a good idea. I think nodelist segments (and diffs) should
    probably be the subject of another document though

    St Louis segments are the same as the complete nodelist, only smaller,
    but they rely on static filenames to figure out who it's from and what
    it's for, which bothers me. If the nodelist contains it's origin,
    basic security, and any necessary dummy hierarchial information, that
    is no longer necessary.

    OK.

    and Password keywords can be described in terms of segment processing
    software and not in terms of the entire nodelist, because it would

    It still needs to be standardised otherwise everyone will come up with their own method :)

    Yep. I'd like to get over the first hurdle of actually getting people used to the idea of a new format though. ;-)

    goes on now to propose what should happen in future. I do think a
    diff format that is standard (like GNU diff/patch) should be used
    rather than the obscure format used with nodediffs now.

    "diff" has a mode that is more or less identical to the current
    nodediff format

    diff -n ?

    I'll add the proper addressing convention in. I'm not sure about the
    "may change" part though. It will never change until people stop
    using FTS-5 nodelists outright for a start.

    You never know. Insufficient separation between Policy and Technical
    lead us to the Pvt,-unpublished- issue, for example.

    I suppose it could happen. ;-)

    I don't actually know what the situation is with the Pvt,-Unpub- issue.

    FTSC_PUBLIC also) about listing non-default/ideal routing is fine
    technically but it may be difficult to get a consensus as to whether
    it's achievable if/when it comes to implementing it

    It's no more difficult than back tracing "uplink" keywords until you
    bump into a node that I'm able to connect to.

    It's not difficult technically. The problem is whether people want to have web-structure routing information in the nodelist in addition to the default tree-structure. Some may not to. But I suppose at the end of the day each ZC will have control over what goes into their nodelist so it's probably not a big
    deal.

    And I should add to the current spec that "keywords in the nodelist
    that are not recognised should be ignored"

    That will limit future developments, as old software will strip out new lines. The equivalent of all IP flags getting removed because an old processor was written before they exists. Best to pass on unknown keywords, the ZC's can determine what's valid in their zones and filter
    out the rest intelligently.

    Yes, "ignore", not "strip out". ;-) I was refering to nodelist parsing software ignoring new keywords it doesn't recognise (instead of failing). Segment merging software shouldn't strip out anything unless it's been told to.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Jasen Betts@3:640/531.42 to Scott Little on Sun Nov 3 13:09:47 2002
    Hi Scott.

    02-Nov-02 09:47:45, Scott Little wrote to andrew clarke

    There should be no technical limit to the number of peers allowed,

    yeah, "technical" limits are a result of lazy programmers.
    software with technical limits often has other shortcomings,

    Bye <=-

    ---
    * Origin: How come wrong numbers are never busy? (3:640/531.42)
  • From mark lewis@1:3634/12 to andrew clarke on Tue Nov 5 14:45:00 2002
    Yes, "ignore", not "strip out". ;-) I was refering to
    nodelist parsing software ignoring new keywords it doesn't
    recognise (instead of failing). Segment merging software
    shouldn't strip out anything unless it's been told to.

    many understand "ignore" to mean completely and thus they ignore those items when copying or modifying and subsequently those items are ignored right out of
    the resultant processing...

    methinks "ignored" is not the proper word to be used...

    )\/(ark


    * Origin: (1:3634/12)
  • From andrew clarke@3:633/267 to mark lewis on Wed Nov 6 07:55:54 2002
    Tue 2002-11-05 14:45, mark lewis (1:3634/12) wrote to andrew clarke:

    Yes, "ignore", not "strip out". ;-) I was refering to
    nodelist parsing software ignoring new keywords it doesn't
    recognise (instead of failing). Segment merging software
    shouldn't strip out anything unless it's been told to.

    many understand "ignore" to mean completely and thus they ignore those items when copying or modifying and subsequently those items are
    ignored right out of the resultant processing...

    methinks "ignored" is not the proper word to be used...

    Yeah, probably not. Like I said, I'm not a documentation writer. I probably have wouldn't have used that word in the actual spec though.

    You may hereby ignore my misuse of the word "ignore" for the remainder of this message!

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Jasen Betts on Wed Nov 6 08:01:54 2002
    Sun 2002-11-03 13:09, Jasen Betts (3:640/531.42) wrote to Scott Little:

    There should be no technical limit to the number of peers allowed,

    yeah, "technical" limits are a result of lazy programmers.
    software with technical limits often has other shortcomings,

    I think you mean "artificially-imposed" limits. I'd be a bit careful to generalise though. Sometimes these limits are necessary because they make software design too complex or impractical without them. This was particularly
    true in the DOS days. It's still relevant now though, eg. a limit of 4,294,967,295 messages per messagebase file is still a limit, even if you can effectively treat it as if there were no limit.

    (I agree with Scott btw. :-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Scott Little@3:712/848 to andrew clarke on Wed Nov 6 09:16:56 2002
    [ 05 Nov 02 11:20, andrew clarke wrote to Scott Little ]

    I couldn't find any ",T:" in my nodelist, so I think that's a
    non-issue, unless I've misunderstood.

    I mean, rather than Txx use T:xx so it's easier to parse.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Wed Nov 6 09:19:58 2002
    [ 05 Nov 02 11:43, andrew clarke wrote to Scott Little ]

    Admittedly it is longer, but it IS human readable. :-)

    Don't get too carried away with human readability - it's primary function is for mailers and other programs, not sysops. If it's too difficult to parse/process it's useless.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From andrew clarke@3:633/267 to All on Wed Nov 6 09:02:24 2002
    Tue 2002-11-05 11:55, andrew clarke (3:633/267) wrote to Jasen Betts:

    did you see what I was proposing a few months back.

    I'm afraid I wasn't in FidoNet a few months back. I left in January

    Actually if anyone reading this happens to have an archive of NET_DEV going back to "a few months back" or preferably even further (like all the way back til Jan '99) that they could send me could they contact me via netmail/e-mail.
    Squish/JAM/*.MSG/PKT/etc are OK. If your netmail happens to bounce because I've only just been nodelisted then you might want to try 3:633/285.4 instead, or crashmail via BinkP at blizzard.dnsalias.org.

    Oh, the same goes for FTSC_PUBLIC too.

    Thanks.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Janis Kracht@1:261/38 to Andrew Clarke on Tue Nov 5 21:37:50 2002
    Hi Andrew,

    I have from 11th December, 1999, in this message base.. I can send them to you in text form, or qwk packets.. BBBS doesn't do re-scans :(

    I only have from January of 2002 in FTSC_PUBLIC though :(

    Take care,
    Janis

    Actually if anyone reading this happens to have an archive of NET_DEV going back to "a few months back" or preferably even further (like all the way back
    til Jan '99) that they could send me could they contact me via netmail/e-mail.
    Squish/JAM/*.MSG/PKT/etc are OK. If your netmail happens to bounce because
    I've only just been nodelisted then you might want to try 3:633/285.4 instead,
    or crashmail via BinkP at blizzard.dnsalias.org.

    Oh, the same goes for FTSC_PUBLIC too.

    Thanks.

    -- mail@ozzmosis.com

    --- BBBS/LiI v4.01 Flag-4
    * Origin: Prism bbs (1:261/38)
  • From andrew clarke@3:633/267 to Janis Kracht on Wed Nov 6 20:03:46 2002
    Tue 2002-11-05 21:37, Janis Kracht (1:261/38) wrote to Andrew Clarke:

    I have from 11th December, 1999, in this message base.. I can send them
    to you in text form, or qwk packets.. BBBS doesn't do re-scans :(

    I only have from January of 2002 in FTSC_PUBLIC though :(

    Thanks, but as it turns out I've just been sent .PKTs of NET_DEV going back to 1997, so now I have virtually every message ever posted here since August 1994!
    And also FTSC_PUBLIC since about the time it started. Both courtesy a sysop in Z2. :-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Thu Nov 7 21:38:52 2002
    Hi andrew.

    >> nodediff format

    diff -n ?

    IMO it's closer to diff --forward-ed


    * Origin: Did you know... That no-one ever reads these things? (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to Scott Little on Wed Nov 6 18:31:28 2002
    Hi Scott.

    05-Nov-02 17:54:52, Scott Little wrote to andrew clarke

    [ 05 Nov 02 10:31, andrew clarke wrote to Scott Little ]

    The hierachy is only important when it comes down to default mail
    routing, and politics. Parsing software should be able to handle

    Thing is, this format requires at least two scans of the nodelist
    to find a node and it's uplink. The only shortcut is to assume an
    uplink of /0 for normal nodes

    Thats what indexes are for. properly indexed it would requre zero scans
    (just two lookups). there's no reason to make the index part of the standard though, that's for the appliction developers to handle - they could even
    import the wholw nodelist it into a SQL database if they want :)

    goes on now to propose what should happen in future. I do think
    a diff format that is standard (like GNU diff/patch) should be
    used rather than the obscure format used with nodediffs now.

    "diff" has a mode that is more or less identical to the current
    nodediff format

    I concurr. the current noddiff format is very similar looking to a gnu/unix diff format

    It's no more difficult than back tracing "uplink" keywords until
    you bump into a node that I'm able to connect to

    as above, an index would definitely help with that,

    And I should add to the current spec that "keywords in the
    nodelist that are not recognised should be ignored"

    Bye <=-

    ---
    * Origin: umop apisdn :zO palle> puel ay+ ui ajaymawoS (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Wed Nov 6 18:43:14 2002
    Hi andrew.

    05-Nov-02 11:20:48, andrew clarke wrote to Scott Little


    Sat 2002-11-02 10:08, Scott Little (3:712/848) wrote to andrew clarke:

    While we're at it, can we standardise the Flags formatting too
    (FTS-5001)? Eg. rather than Txx T:xx, making it simpler to parse them
    generically.

    I couldn't find any ",T:" in my nodelist, so I think that's a non-issue, unless
    I've misunderstood

    He's pushing to separate the data part from the identifier part.

    The way we have it there's over 2000 different Txy type flags possible

    by putting the colon in in the new format there's one T: that has a 2
    character data field after it.

    otherwise you make T a special case when parsing the nodelist and speaciual cases are yucky and tend to cause problems in the future,

    personally I'd prefer to replace the Txy flag with TIME:xy or similar conversion software (to produce FTS5 nodelists) should be able to to that conversion.

    Bye <=-

    ---
    * Origin: Save energy: be apathetic. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Wed Nov 6 19:14:37 2002
    >> Mainly leting a node have multiple addresses (since many do) and
    >> thus saving repeating the same node with the same connection info
    >> and thus make the nodelist easier to maintain?

    I don't see any reason why a single node shouldn't be able to have multiple connection methods listed in a new format nodelist.

    I agree, what I'm suggesting is where one physical fidonet system has
    multiple fido addresses (eg as an NC and as a regular node)
    they could somehow list both addresses in the single nodelist record.

    in the current nodelist you see some entries where the same system is
    listed twice because they can't fit everything the want on a single
    nodleist line.

    OTOH I guess they could just list the other addess as a preferred uplink
    and that'd probably do most of what's needed.


    Bye <=-

    ---
    * Origin: Misery loves company, but company does not reciprcate (3:640/531.42)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 01:30:42 2002
    Wed 2002-11-06 09:16, Scott Little (3:712/848) wrote to andrew clarke:

    I couldn't find any ",T:" in my nodelist, so I think that's a
    non-issue, unless I've misunderstood.

    I mean, rather than Txx use T:xx so it's easier to parse.

    Well, firstly, that's something you should really take up with whoever wants to
    modify FTS-5001, ie. not me. Also Tyz is the format people are using in my current nodelist so presumably they aren't going see any reason to change. As for actually parsing it, it's seems simple enough to me - if the nodelist flag begins in T and contains non-alphabetic characters or isn't 3 characters long then it must be something else. But if it is a valid Tyz string then you just need a lookup table.

    Either way, programs that convert the HRL nodelist to FTS-5/5001 format should copy the string in the "Operating Dialup FTS-1 at" line verbatim. So it's like two nodelists in one, really.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 01:42:56 2002
    Wed 2002-11-06 09:19, Scott Little (3:712/848) wrote to andrew clarke:

    Admittedly it is longer, but it IS human readable. :-)

    Don't get too carried away with human readability - it's primary
    function is for mailers and other programs, not sysops. If it's too difficult to parse/process it's useless.

    I can't decide whether you're saying it's too difficult to parse or not. Did you look at the source code I wrote? (Anyone?)

    http://blizzard.dnsalias.org/fidonet/nodelist/

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Jasen Betts on Sun Nov 10 01:47:16 2002
    Wed 2002-11-06 18:43, Jasen Betts (3:640/531.42) wrote to andrew clarke:

    While we're at it, can we standardise the Flags formatting too
    (FTS-5001)? Eg. rather than Txx T:xx, making it simpler to
    parse them generically.

    I couldn't find any ",T:" in my nodelist, so I think that's a
    non-issue, unless I've misunderstood

    He's pushing to separate the data part from the identifier part.

    The way we have it there's over 2000 different Txy type flags possible

    by putting the colon in in the new format there's one T: that has a 2 character data field after it.

    otherwise you make T a special case when parsing the nodelist and
    speaciual cases are yucky and tend to cause problems in the future,

    If the nodelist flag begins in T and contains non-alphabetic characters or isn't 3 characters long then it must be something else - right? But if isn't "something else", then all you need is a simple lookup table.

    personally I'd prefer to replace the Txy flag with TIME:xy or similar conversion software (to produce FTS5 nodelists) should be able to to
    that conversion.

    I don't think you can, because FTS-5001 has made it a standard. And you can't change standards, only add to them. With the only red herring being that the standard has "expired", but that shouldn't change people's attitude towards it,
    because (presumably) software was written to the standard when it applied.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Scott Little@3:712/848 to Rick Van Ruth on Sun Nov 10 13:47:15 2002
    [ 10 Nov 02 09:38, Rick Van Ruth wrote to andrew clarke ]

    I had a look at the nodelist it generated, but sorry I don't agree
    with the fields

    Feel free to share specifics..


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Rick Van Ruth@3:640/954 to Scott Little on Sun Nov 10 13:22:56 2002
    Hello Scott.

    10 Nov 02 13:47, you wrote to me:

    I had a look at the nodelist it generated, but sorry I don't agree
    with the fields

    Feel free to share specifics..

    I don't understand why some information is given a line for the field yet the connection information is still all in one line. I figure if you were going
    to use this type of format there would be a greater number of defining lines.

    It merely appears to be using the existing format and transferring it into 7 lines instead of one.

    Cheers,
    Rick

    ... THE fIRST sTEP iS tO tAKE oFF tHE cAPS lOCK.
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 09:38:39 2002
    Hello andrew.

    10 Nov 02 01:42, you wrote to Scott Little:

    Don't get too carried away with human readability - it's primary
    function is for mailers and other programs, not sysops. If it's too
    difficult to parse/process it's useless.

    I can't decide whether you're saying it's too difficult to parse or not. Did you look at the source code I wrote? (Anyone?)

    http://blizzard.dnsalias.org/fidonet/nodelist/

    I had a look at the nodelist it generated, but sorry I don't agree with the fields, but then I guess you haven't yet decided the final format.

    Cheers,
    Rick

    ... I don't have the time for a hobby. I have a computer.
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 10 10:44:04 2002
    [ 10 Nov 02 01:42, andrew clarke wrote to Scott Little ]

    I can't decide whether you're saying it's too difficult to parse or
    not.

    Fully specifying the address for each node bothers me, esp. in conjunction with
    the Uplink field.

    * Initial version. Currently the Uplink field in the human-readable
    * nodelist is ignored by rnlcvt. Which assumes the input file is already
    * in hierarchical order.

    A _correct_ implementation will be more complex unnecessarily in the name of human readability. Much easier to extract a human readable list from a strict format than the other way around.

    St Louis and XML both enforce proper structure in the format itself, without relying on ignorable rules in the specification. (and eventually someone will try an alternate use for the Uplink, you watch)

    Did you look at the source code I wrote? (Anyone?)

    I don't do C so it's not much good to me :)


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 10 11:15:37 2002
    [ 10 Nov 02 01:47, andrew clarke wrote to Jasen Betts ]

    I don't think you can, because FTS-5001 has made it a standard. And
    you can't change standards, only add to them.

    What about FTS-5000?

    I'm trying to have both standards replaced with something slightly more sensible and less crufty.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From mark lewis@1:3634/12 to andrew clarke on Sun Nov 10 01:58:54 2002
    I don't think you can, because FTS-5001 has made it
    a standard. And you can't change standards, only add
    to them.

    What about FTS-5000?

    I'm trying to have both standards replaced with something
    slightly more sensible and less crufty.

    You can only extend the standard or obsolete it. That is,
    unless the ZCs decide FTS-5000 isn't really a standard after
    all, because it's "expired", which is unfair to all the
    developers who wrote software in accordance with that spec
    between the time it became a standard and the time it expired.
    (In other words, having standards documents expire is a
    really bad idea!)

    the reason the present/last FTSC decided to put in expiration dates was to force them to revisit the expiring standard and to update it or whatever was needed before it expired... this was supposed to keep the FTSC alive and also to ensure that we had current and up to date standards to work from...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to andrew clarke on Sun Nov 10 02:01:00 2002
    I don't know what alternate use people would use for the
    Uplink keyword, but it won't matter, because the spec won't
    allow them to. And anyone using broken software that doesn't
    comply to the spec would be risking being denodelisted until
    they stop using it presumably.

    erm... the current use of the "BBS Name" field in the currently used St. Louis Format (SLF) nodelist as a domain name instead of the system name is one such example of an alternative use... granted, its not being misused in what you are
    proposing or working on but it is a possibility that someone may do the same...

    )\/(ark


    * Origin: (1:3634/12)
  • From Scott Little@3:712/848 to Rick Van Ruth on Sun Nov 10 16:53:51 2002
    [ 10 Nov 02 13:22, Rick Van Ruth wrote to Scott Little ]

    I don't understand why some information is given a line for the field
    yet the connection information is still all in one line.

    His program isn't a full implementation of the proposal.. otherwise there'd be entries like:

    Operating Dialup FTS-1 at 61-1-1234-5678,XA Sat 00:00-06:00
    Operating TCP/IP Binkp at 127.0.0.1 Sun 00:00-06:00


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 10 17:02:24 2002
    [ 10 Nov 02 16:00, andrew clarke wrote to Scott Little ]

    Fully specifying the address for each node bothers me, esp. in
    conjunction with the Uplink field.
    Why?

    It allows nodes to be where they shouldn't be.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 10 17:03:16 2002
    [ 10 Nov 02 16:07, andrew clarke wrote to Scott Little ]

    You can only extend the standard or obsolete it.

    Ok, Txy is obsolete. T:xy is the new standard.

    Better?

    The reason I mention it to you is because it's easier to have the flag translations built into the node translation that it would be to modify it later after native HRN software is already using Txy.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Sun Nov 10 17:08:51 2002
    [ 10 Nov 02 16:19, andrew clarke wrote to Scott Little ]

    If there are rules in the spec, they can't be ignored!

    Uh, why are we here? Coz everyone's ignoring the nodelist specs and putting shit everywhere under all manner of status flags (Pvt, Hold and whatnot).

    You just can't do that. ;-)

    They can and will.. mark my words </cranky old fart>

    I don't know what alternate use people would use for the Uplink

    They can use it as their echomail route instead of Host route. It's more likely that you may think...

    (fast forward 10 years)

    With the demise of Regions and Hubs, there is no now no need for the Uplink keyword - the node number itself contains all the information necessary. But since much software uses it to route mail, we can reuse it as the echomail route, rather than Host route.

    [HRN processors designed to enforce the spec explode because people list invalid uplinks; Dale tells them all to upgrade their software or piss off]


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 18:41:13 2002
    Hello andrew.

    10 Nov 02 15:57, you wrote to me:

    I had a look at the nodelist it generated, but sorry I don't agree with
    the fields, but then I guess you haven't yet decided the final format.

    You'll have to tell me what you don't agree with specifically, otherwise I've got no reason to change it!

    I don't see any difference over the current listing method, the exact same information appears in your format with the only difference (except for "Parent") is that is is listed in lines and has the field names present.

    What advantage does this give?

    Also what is the point of having "Parent"?

    Cheers,
    Rick

    ... Push red button to test, release to detonate...
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 18:46:44 2002
    Hello andrew.

    10 Nov 02 16:34, you wrote to Scott Little:

    I don't know what alternate use people would use for the Uplink
    keyword, but it won't matter, because the spec won't allow them to.

    Maybe if I just called it Parent, and Uplink was not a synonym for
    Parent, there would be less confusion about its purpose.

    Then the Uplink keyword could be used for specifying non-default routing information, if necessary.

    I don't understand what there is to gain from the format.

    Cheers,
    Rick

    ... Radioactive cats have 18 half-lives.
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Rick Van Ruth@3:640/954 to Scott Little on Sun Nov 10 18:47:41 2002
    Hello Scott.

    10 Nov 02 16:53, you wrote to me:

    I don't understand why some information is given a line for the field
    yet the connection information is still all in one line.

    His program isn't a full implementation of the proposal.. otherwise there'd be entries like:

    Operating Dialup FTS-1 at 61-1-1234-5678,XA Sat 00:00-06:00
    Operating TCP/IP Binkp at 127.0.0.1 Sun 00:00-06:00

    Then I guess I need to see a full example of the implementation.

    Got any?

    Cheers,
    Rick

    ... Operator, trace this call and tell me where I am.
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Scott Little@3:712/848 to Rick Van Ruth on Sun Nov 10 20:47:17 2002
    [ 10 Nov 02 18:41, Rick Van Ruth wrote to andrew clarke ]

    Also what is the point of having "Parent"?

    Because irritatingly, the full Fidonet hierarchy isn't represented in the node number. To find out what Region or Hub a node is in you have to trace backwards up the Parent tree.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to Rick Van Ruth on Sun Nov 10 20:52:11 2002
    [ 10 Nov 02 18:47, Rick Van Ruth wrote to Scott Little ]

    Then I guess I need to see a full example of the implementation.
    Got any?

    Erm, sorta. I generated a list using the routing address syntax (fugly, but it
    contains the full node hierarchy) to see what it would look like. Just pretend
    the keywords are to Andrew's specs instead... and ignore the blank keywords and
    other dodginess :)

    http://members.optushome.com.au/rtscts/rnl.zip


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 20:33:14 2002
    Sun 2002-11-10 17:03, Scott Little (3:712/848) wrote to andrew clarke:

    You can only extend the standard or obsolete it.

    Ok, Txy is obsolete. T:xy is the new standard.

    Better?

    Now try getting that past the FTSC. Oh wait, you can't. Damn.

    I don't see any need to change from Txy to T:xy really. Whoever gets elected to the FTSC may have a different idea though.

    The reason I mention it to you is because it's easier to have the flag translations built into the node translation that it would be to modify
    it later after native HRN software is already using Txy.

    No need. The idea is to get HRN used as the primary nodelist format used for distribution by the ZCs. Then people without a HRN compiler can use software (like rnlcvt but more complete) to convert to St Louis. Once that's done, the St Louis flags after the "Operating [Dialup] [FTS-1] [at] [phonenumber]" should
    be copied verbatim from the HRN if you're converting to St Louis format. But people shouldn't be _regularly_ converting the existing St Louis nodelist to HRN format
    unless they have a dire need to (because the nodelist will normally be distributed in HRN format by the ZCs). That's the plan, anyway!

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 20:57:44 2002
    Sun 2002-11-10 17:08, Scott Little (3:712/848) wrote to andrew clarke:

    If there are rules in the spec, they can't be ignored!

    Uh, why are we here? Coz everyone's ignoring the nodelist specs and putting shit everywhere under all manner of status flags (Pvt, Hold and whatnot).

    You just can't do that. ;-)

    They can and will.. mark my words </cranky old fart>

    Well, I'm not saying they won't. Nothing will stop people doing incorrect things. The point is the spec won't allow them to and still be conformant.

    In terms of FTS-5/5000/5001, what there really needs to be is another document listing all the things you specifically can't do in the nodelist, and why, and/or what software will break if you do, because it seems fairly obvious that
    people don't want to stop using software from 10+ years ago, eg. MAKENL.

    I don't know what alternate use people would use for the Uplink

    They can use it as their echomail route instead of Host route. It's
    more likely that you may think...

    Yeah, OK. Just using Parent instead of Uplink should stop any confusion there.
    Hopefully!

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Rick Van Ruth@3:640/954 to Scott Little on Sun Nov 10 21:15:45 2002
    Hello Scott.

    10 Nov 02 20:47, you wrote to me:

    Also what is the point of having "Parent"?

    Because irritatingly, the full Fidonet hierarchy isn't represented in
    the node number. To find out what Region or Hub a node is in you have
    to trace backwards up the Parent tree.

    Couldn't that be done just via the organisation of the nodelist file? Or is that something that is being trying to be overcme?


    Cheers,
    Rick

    ... Xerox never comes up with anything original.
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Rick Van Ruth@3:640/954 to Scott Little on Sun Nov 10 21:21:46 2002
    Hello Scott.

    10 Nov 02 20:52, you wrote to me:

    Then I guess I need to see a full example of the implementation.
    Got any?

    Erm, sorta. I generated a list using the routing address syntax (fugly, but it contains the full node hierarchy) to see what it would look like. Just pretend the keywords are to Andrew's specs instead... and ignore
    the blank keywords and other dodginess :)

    http://members.optushome.com.au/rtscts/rnl.zip

    Ok, I see.. but I still don't understand :-)

    I can see you can have multiple "link" fields in yours, I assume a link line for each phone number or domain/ net address?

    Are there any other fields for the format? Like fields that currently don't have relevance to the St Louis format but are included in this format for future expansion?

    Cheers,
    Rick

    ... Put your hard drive to your ear. Can you hear the C:?
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 21:58:31 2002
    Hello andrew.

    10 Nov 02 20:57, you wrote to Scott Little:

    I don't know what alternate use people would use for the Uplink

    They can use it as their echomail route instead of Host route. It's
    more likely that you may think...

    Yeah, OK. Just using Parent instead of Uplink should stop any confusion there. Hopefully!

    Why do you need either Parent or Uplink if its just to determine host routed mail? Wouldn't the order of your format dictate the host routing?

    Cheers,
    Rick

    ... I*love~my$computer,;It's%made in Taiwa~##$ ` #@
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From andrew clarke@3:633/267 to mark lewis on Sun Nov 10 21:45:30 2002
    Sun 2002-11-10 01:58, mark lewis (1:3634/12) wrote to andrew clarke:

    the reason the present/last FTSC decided to put in expiration dates was
    to force them to revisit the expiring standard and to update it or
    whatever was needed before it expired... this was supposed to keep the
    FTSC alive and also to ensure that we had current and up to date
    standards to work from...

    Well that worked well. I hope it didn't have the opposite effect and drive them all away! </conspiracy>

    ;-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to mark lewis on Sun Nov 10 21:47:36 2002
    Sun 2002-11-10 02:01, mark lewis (1:3634/12) wrote to andrew clarke:

    I don't know what alternate use people would use for the
    Uplink keyword, but it won't matter, because the spec won't
    allow them to. And anyone using broken software that doesn't
    comply to the spec would be risking being denodelisted until
    they stop using it presumably.

    erm... the current use of the "BBS Name" field in the currently used
    St. Louis Format (SLF) nodelist as a domain name instead of the system
    name is one such example of an alternative use... granted, its not
    being misused in what you are proposing or working on but it is a possibility that someone may do the same...

    Field 3: Node name

    FTS-5 = "This is the name by which the node is known"

    FTS-5000 = "This is the name by which the node is known. For IP nodes this field may alternately contain an ip address or E-Mail address for email tunneling programs."

    Nothing about a BBS name there. Not that I even run a BBS, but for people who do, why should they care about what's in that field anyway? What difference does it make? Maybe the ZCs can all mark the field with a big X for every node
    in their zone. Then it would make the nodelist smaller for all the people complaining about the nodelist being too big. Then you'll get people whinging about how the nodelist is shrinking and we're all doomed. So we're all doomed.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 21:58:26 2002
    Sun 2002-11-10 16:53, Scott Little (3:712/848) wrote to Rick Van Ruth:

    I don't understand why some information is given a line for the field
    yet the connection information is still all in one line.

    His program isn't a full implementation of the proposal..

    (because it's not really possible)

    otherwise there'd be entries like:

    Operating Dialup FTS-1 at 61-1-1234-5678,XA Sat 00:00-06:00
    Operating TCP/IP Binkp at 127.0.0.1 Sun 00:00-06:00

    Not quite. More like:

    Address 3:456/789
    Operating Dialup FTS-1 at 61-1-1234-5678,XA
    Online Sat 00:00-06:00

    Address 3:456/789
    Operating TCP/IP Binkp at 127.0.0.1
    Online Sun 00:00-06:00

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Sun Nov 10 22:00:24 2002
    Sun 2002-11-10 18:41, Rick Van Ruth (3:640/954) wrote to andrew clarke:

    I had a look at the nodelist it generated, but sorry I don't agree
    with the fields, but then I guess you haven't yet decided the final
    format.

    You'll have to tell me what you don't agree with specifically,
    otherwise I've got no reason to change it!

    I don't see any difference over the current listing method, the exact
    same information appears in your format with the only difference
    (except for "Parent") is that is is listed in lines and has the
    field names present.

    What advantage does this give?

    The same information appears in my format to allow it to be converted to St Louis format. But there are additional fields to allow BinkP nodes to be described adequately. And scope to allow other methods of communication. I thought my proposal explained that.

    Also what is the point of having "Parent"?

    To allow nodes to be listed in any order in the HRL.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Sun Nov 10 22:02:46 2002
    Sun 2002-11-10 18:47, Rick Van Ruth (3:640/954) wrote to Scott Little:

    Then I guess I need to see a full example of the implementation.

    Well, I can only show you an example of what I _think_ is correct, because only
    the sysop of the node can give an authoritive answer, which is why I didn't bother converting any of the St Louis flags to BinkP entries in the HRN. But here are some examples based my limited knowledge of the systems concerned:

    Address 3:3/0
    Status Zone
    Name Australia NZ PNG
    Location North Balwyn Vic
    Operator Malcolm Miles
    Operating Dialup FTS-1 at 61-3-9819-7093,9600,V34,V32b,VFC,V42b,CM,XA
    Operating TCP/IP BinkP at fido.tardis.net
    ; I don't remember Malcolm's e-mail address
    Contact E-mail ???@tardis.net

    Address 3:55/0
    Parent 3:3/0
    Status Region
    Name FIVE EIGHTHS Of AUSTRALIA
    Location PERTH
    Operator Stephen Gibbs
    Operating Dialup FTS-1 at 61-8-9275-9488,9600,CM,V32b,V42b,XA
    ; I don't know if Stephen runs BinkP

    Address 3:633/0
    Parent 3:55/0
    Status Host
    Name Melbourne East
    Location Scoresby
    Operator Ger Vloothuis
    Operating Dialup FTS-1 at 61-3-9763-5631,9600,V32b,CM,XA,IBN:scoresby.pbn.com.au,IEM:irex@pbn.com.au
    Operating TCP/IP BinkP at scoresby.pbn.com.au
    Contact E-mail ger@ttq.dialix.oz.au

    Address 3:633/100
    Parent 3:633/0
    Status Hub
    Name Hub 100
    Location Scoresby
    Operator Ger Vloothuis
    Operating Dialup FTS-1 at 61-3-9763-5631,9600,V32b,CM,XA,IBN:scoresby.pbn.com.au,IEM:irex@pbn.com.au
    Operating TCP/IP BinkP at scoresby.pbn.com.au
    Contact E-mail ger@ttq.dialix.oz.au

    Address 3:633/267
    Parent 3:633/100
    Status Private
    Name Blizzard of Ozz
    Location Mt Eliza Vic
    Operator andrew clarke
    Operating Dialup FTS-1 at -Unpublished-,300,CM,XA,IBN:blizzard.dnsalias.org,IEM:mail@ozzmosis.com
    Operating TCP/IP BinkP at blizzard.dnsalias.org
    Contact E-mail mail@ozzmosis.com
    Contact Fax +61-3-9775-2610

    Address 1:379/1
    Parent 1:379/0
    Status Private
    Name Fido Mail Hub
    Location Pine Harbor NC
    Operator Dale Ross
    Operating Dialup FTS-1 at -Unpublished-,300,CM,IFT,IBN:BinkP.HarborWebs.com,ITN:60177,U,PING,MRVIA:1:379/1
    Operating TCP/IP BinkP at binkp.harborwebs.com
    Contact E-mail dale@harborwebs.com

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 23:19:00 2002
    Hello andrew.

    10 Nov 02 22:02, you wrote to me:

    Well, I can only show you an example of what I _think_ is correct,
    because only the sysop of the node can give an authoritive answer, which is why I didn't bother converting any of the St Louis flags to BinkP entries in the HRN. But here are some examples based my limited
    knowledge of the systems
    concerned:

    Address 3:633/267
    Parent 3:633/100
    Status Private
    Name Blizzard of Ozz
    Location Mt Eliza Vic
    Operator andrew clarke
    Operating Dialup FTS-1 at -Unpublished-,300,CM,XA,IBN:blizzard.dnsalias.org,IEM:mail@ozzmosis.com Operating TCP/IP BinkP at blizzard.dnsalias.org
    Contact E-mail mail@ozzmosis.com Contact Fax +61-3-9775-2610

    Why mention binkp twice? Just for backward compatability's sake?

    Why does binkp get a line to itself yet email transfer does not?

    If your system is online 24/7 via IP why is your status private?

    Excuse the questions, but I am not quite following the advantages/reasons as yet.

    Cheers,
    Rick

    ... Classified tagline. Please enter password: _
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Mon Nov 11 00:04:44 2002
    Sun 2002-11-10 21:58, Rick Van Ruth (3:640/954) wrote to andrew clarke:

    I don't know what alternate use people would use for the Uplink

    They can use it as their echomail route instead of Host route. It's
    more likely that you may think...

    Yeah, OK. Just using Parent instead of Uplink should stop any
    confusion there. Hopefully!

    Why do you need either Parent or Uplink if its just to determine host routed mail? Wouldn't the order of your format dictate the host routing?

    Because the HRL won't necessarily list nodes in hierachical order, although maybe it should, just to reduce confusion.

    What do others think? Should a new nodelist format list nodes in hierachical order like the St Louis format does? And why. ;-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Rick Van Ruth@3:640/954 to andrew clarke on Sun Nov 10 23:36:20 2002
    Hello andrew.

    11 Nov 02 00:04, you wrote to me:

    What do others think? Should a new nodelist format list nodes in hierachical order like the St Louis format does? And why. ;-)

    Yes, in case someone wants to manually update their listing without using a utility program. Having it in order will make finding it easier.

    Same goes for people who like to "browse" the nodelist.

    Cheers,
    Rick

    ... Sure I know how to copy disks, where's the Xerox?
    --- GoldED+/LNX 1.1.5 - Debian/GNU
    * Origin: Vampyre's Heaven BBS (3:640/954)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Sun Nov 10 15:57:08 2002
    Sun 2002-11-10 09:38, Rick Van Ruth (3:640/954) wrote to andrew clarke:

    http://blizzard.dnsalias.org/fidonet/nodelist/

    I had a look at the nodelist it generated, but sorry I don't agree with
    the fields, but then I guess you haven't yet decided the final format.

    You'll have to tell me what you don't agree with specifically, otherwise I've got no reason to change it!

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 16:00:44 2002
    Sun 2002-11-10 10:44, Scott Little (3:712/848) wrote to andrew clarke:

    I can't decide whether you're saying it's too difficult to parse or
    not.

    Fully specifying the address for each node bothers me, esp. in
    conjunction with the Uplink field.

    Why?

    * Initial version. Currently the Uplink field in the human-readable
    * nodelist is ignored by rnlcvt. Which assumes the input file is
    * already in hierarchical order.

    A _correct_ implementation will be more complex unnecessarily in the
    name of human readability.

    Not really. But keep in mind that rnlcvt's aim was just to check the valididty
    of nlcvt's output.

    Much easier to extract a human readable list from a strict format
    than the other way around.

    True. But still pretty simple.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 16:07:58 2002
    Sun 2002-11-10 11:15, Scott Little (3:712/848) wrote to andrew clarke:

    I don't think you can, because FTS-5001 has made it a standard. And
    you can't change standards, only add to them.

    What about FTS-5000?

    I'm trying to have both standards replaced with something slightly more sensible and less crufty.

    You can only extend the standard or obsolete it. That is, unless the ZCs decide FTS-5000 isn't really a standard after all, because it's "expired", which is unfair to all the developers who wrote software in accordance with that spec between the time it became a standard and the time it expired. (In other words, having standards documents expire is a really bad idea!)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 16:19:32 2002
    Sun 2002-11-10 10:44, Scott Little (3:712/848) wrote to andrew clarke:

    St Louis and XML both enforce proper structure in the format itself, without relying on ignorable rules in the specification. (and
    eventually someone will try an alternate use for the Uplink, you watch)

    If there are rules in the spec, they can't be ignored! That's like saying "I'm
    going to comply with FTS-9, but I'm going to ignore the requirement to generate
    serial numbers in a three year period, bugger that, let's make it three weeks instead." You just can't do that. ;-)

    I don't know what alternate use people would use for the Uplink keyword, but it
    won't matter, because the spec won't allow them to. And anyone using broken software that doesn't comply to the spec would be risking being denodelisted until they stop using it presumably.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Sun Nov 10 16:28:16 2002
    Sun 2002-11-10 13:22, Rick Van Ruth (3:640/954) wrote to Scott Little:

    I had a look at the nodelist it generated, but sorry I don't agree
    with the fields

    Feel free to share specifics..

    I don't understand why some information is given a line for the field
    yet the connection information is still all in one line.

    The "Operating Dialup FTS-1 at" was designed to be backward compatible with the
    St Louis nodelist, so you could copy anything after that string back into the St Louis nodelist.

    I figure if you were going to use this type of format there would be
    a greater number of defining lines.

    What for? Other connection methods than FTS-1 and BinkP? There is scope for more if needed, eg. "Operating TCP/IP VMODEM at example.org". Which reminds me, there's no method to specify an alternate BinkP port number in my proposal,
    so I'll have to fix that. Something like

    Operating [TCP/IP] [Binkp] [at] [host] [port]

    Where [port] is optional, and if unspecified, the default BinkP port will be used.

    Regards
    Andrew

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Scott Little on Sun Nov 10 16:34:34 2002
    Sun 2002-11-10 16:19, andrew clarke (3:633/267) wrote to Scott Little:

    I don't know what alternate use people would use for the Uplink
    keyword, but it won't matter, because the spec won't allow them to.

    Maybe if I just called it Parent, and Uplink was not a synonym for Parent, there would be less confusion about its purpose.

    Then the Uplink keyword could be used for specifying non-default routing information, if necessary.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From mark lewis@1:3634/12 to Scott Little on Sun Nov 10 11:13:24 2002
    (fast forward 10 years)

    With the demise of Regions and Hubs, there is no now no need
    for the Uplink keyword - the node number itself contains all
    the information necessary. But since much software uses it to
    route mail, we can reuse it as the echomail route, rather than
    Host route.

    [HRN processors designed to enforce the spec explode because
    people list invalid uplinks; Dale tells them all to upgrade
    their software or piss off]

    ┌┬──┐ ┌┬──┐ ┌─┬┬─┐ ┌┬──┐ ┌┐ ┌┬─┬─┐ ┌┬──┐ ┌┬──┐ ┌┬┐ ┌┬┐ ┌┬┐ ┌┬┐ ┌┬┐ ┌┬┐
    ├┼─┬┘ ├┤ │ ├┤ ├┼─ ├┤ ├┤ │ │ ├┼──┤ ├┤ │ └┴┘ └┴┘ └┴┘ └┴┘ └┴┘ └┴┘
    └┘ └ └┴──┘ └┘ └┘ └┴──┘ └┘ ┘ ┘ └┘ ┘ └┴──┘ o o o o o o



    ▒▒
    ▒▒
    ▒▒▒▒
    ▄▄████████▄▄
    ▄█████▀▀▀▀█████▄
    █████▀ ▀█████
    ▐████ ████▌
    ▄ █████▄ ▄█████ ▄
    ▄██▄ ▀█████▄▄▄▄█████▀ ▄██▄
    ███▀▀█▄ ▀▀▀██████▀▀▀ ▄█▀▀███
    ███ ▀███ ▄▄▄▄▄▄ ███▀ ███
    ███▄ ▄███ ██████ ███▄ ▄███
    ██████▀ █ ██████ █ ▀██████
    ▀████ █ ██████ █ ████▀
    ▀███▄█▀ ██████ ▀█▄███▀
    ▀▀▀▀ ████████ ▀▀▀▀
    ▒▒▒▒▒▒▒▒▒▒▒▒ ████████ ▒▒▒▒▒▒▒▒▒
    ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ████████ ▒▒▒▓▓▓▓▓▒▒▒
    ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ████████ ▒▒▒▓▓▓▓▓▓▓▒▒
    ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ████████ ▒▒▒▓▓▓▓▓▒▒▒
    ▒▒▒▒▒▒▒▒▒▒▒▒ ████████ ▒▒▒▒▒▒▒▒▒
    ████████
    ▒▒▒▒▒▒▒▒▒▄ ▒▒▒▒▄ ▒▒▒▒▒▒▒▒▄ ▒▒▒▒▒▒▒▒▒▒▄ ▒▒▄ ▒▒▄ ▒▒▄ ▒▒▄
    ▒▒█▀▀▀▒▒█ ▒▒█▀ ▒▒█▀▀▀▒▒█ ▒▒█▀▒▒█▀▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█
    ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█
    ▒▒▒▒▒▒▒█▀ ▒▒█ ▒▒▒▒▒▒▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█
    ▒▒█▀▀▀▒▒█ ▒▒█ ▒▒█▀▀▀▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█
    ▒▒█ ▒▒█ ▒▒█ ▒▒▄ ▒▒█ ▒▒█ ▒▒█ ▀▀ ▒▒█ ▀▀ ▀▀ ▀▀ ▀▀
    ▒▒▒▒▒▒▒▒▒█ ▒▒▒▒▒▒▒▒▒█ ▒▒▒▒█ ▒▒▒▒█ ▒▒▒▒█ ▒▒▒▒█ ▒▒▄ ▒▒▄ ▒▒▄ ▒▒▄


    )\/(ark


    * Origin: (1:3634/12)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Mon Nov 11 03:43:38 2002
    Sun 2002-11-10 23:19, Rick Van Ruth (3:640/954) wrote to andrew clarke:

    Operating Dialup FTS-1 at
    -Unpublished-,300,CM,XA,IBN:blizzard.dnsalias.org,IEM:mail@ozzmosis.com
    Operating TCP/IP BinkP at blizzard.dnsalias.org Contact E-mail
    mail@ozzmosis.com Contact Fax +61-3-9775-2610

    Why mention binkp twice? Just for backward compatability's sake?

    Yes.

    Why does binkp get a line to itself yet email transfer does not?

    Because I haven't written a proposal for that. It could, easily.

    If your system is online 24/7 via IP why is your status private?

    Backward compatbility with FTS-5.

    Excuse the questions, but I am not quite following the
    advantages/reasons as yet.

    OK.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Rick Van Ruth on Mon Nov 11 03:45:54 2002
    Sun 2002-11-10 23:36, Rick Van Ruth (3:640/954) wrote to andrew clarke:

    What do others think? Should a new nodelist format list nodes in
    hierachical order like the St Louis format does? And why. ;-)

    Yes, in case someone wants to manually update their listing without
    using a utility program. Having it in order will make finding it
    easier.

    Finding what?

    Same goes for people who like to "browse" the nodelist.

    Yeah, maybe. But then I have Scott Little telling me "don't get too carried away with human readability"! I can't win. ;-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From mark lewis@1:3634/12 to andrew clarke on Sun Nov 10 13:39:28 2002
    the reason the present/last FTSC decided to put in
    expiration dates was to force them to revisit the
    expiring standard and to update it or whatever was
    needed before it expired... this was supposed to
    keep the FTSC alive and also to ensure that we had
    current and up to date standards to work from...

    Well that worked well. I hope it didn't have the opposite
    effect and drive them all away! </conspiracy>

    hehehe... well, if they had not gone to sleep at the wheel, it would have worked just fine... one of the complaints in the past was that standards weren't being updated or removed when they changed or dropped from common practise...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to andrew clarke on Sun Nov 10 13:41:50 2002
    erm... the current use of the "BBS Name" field in the currently used
    St. Louis Format (SLF) nodelist as a domain name instead of the system
    name is one such example of an alternative use... granted, its not
    being misused in what you are proposing or working on but it is a
    possibility that someone may do the same...

    Field 3: Node name

    FTS-5 = "This is the name by which the node is known"

    FTS-5000 = "This is the name by which the node is known. For
    IP nodes this field may alternately contain an ip address or
    E-Mail address for email tunneling programs."

    Nothing about a BBS name there.

    thank you! you've helped me in ways that we may not be aware of ;-)


    Not that I even run a BBS,
    but for people who do, why should they care about what's in
    that field anyway? What difference does it make? Maybe the
    ZCs can all mark the field with a big X for every node in
    their zone. Then it would make the nodelist smaller for all
    the people complaining about the nodelist being too big. Then
    you'll get people whinging about how the nodelist is shrinking
    and we're all doomed. So we're all doomed.

    hahaha... yup, as is birth is the beginning of death...

    )\/(ark


    * Origin: (1:3634/12)
  • From Frank Vest@1:124/6308.1 to andrew clarke on Sun Nov 10 15:25:48 2002
    On (10 Nov 02) andrew clarke wrote to mark lewis...

    Hello andrew,


    Field 3: Node name
    FTS-5 = "This is the name by which the node is known"
    FTS-5000 = "This is the name by which the node is known. For IP nodes this field may alternately contain an ip address or E-Mail address for email tunneling programs."

    Nothing about a BBS name there. Not that I even run a BBS, but for
    people who do, why should they care about what's in that field anyway?

    The "big deal" about the "name field" in the Nodelist was that some
    programs were written to generate "BBS" lists from the Nodelist.

    Since in the beginning of Fidonet most Nodes did operate a BBS (almost
    a requirement to get a Node number), The BBS name in the "Node Name"
    field was a "big deal".

    What difference does it make? Maybe the ZCs can all mark the field

    In a technical sense, it makes no difference. The field is "just
    another field" and could be defined anyway desired.


    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 andrew clarke on Sun Nov 10 15:40:55 2002
    On (11 Nov 02) andrew clarke wrote to Rick Van Ruth...

    Hello andrew,

    Because the HRL won't necessarily list nodes in hierachical order, although maybe it should, just to reduce confusion.

    What do others think? Should a new nodelist format list nodes in hierachical order like the St Louis format does? And why. ;-)

    From a non-technical point of view. "Region" is more of a "point of
    reference" than anything. The Node number is "Zone:Net/Node.Point, not "Zone:Region/Net/Node.Point :)

    The St. Louis format lists in an order that divide the Nodelist into
    Regions as a reference and division. With the St. Louis format, there
    could be several "Net100"s in different Regions and/or Regions in
    Zones.

    A new format should have an "order" and that "order", if adopted,
    would be the Hierarchy. IE:
    1:100/100
    1:101/100
    and so forth. The simple act of numerical order is a Hierarchy. :)

    So, if Fidonet is to keep the current Zone Region Net Node hierarchy,
    yes, we need that in the new format. If not, then no, we don't need
    it.

    Confused yet?? :-)


    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 Scott Little@3:712/848 to andrew clarke on Mon Nov 11 10:59:27 2002
    [ 10 Nov 02 20:33, andrew clarke wrote to Scott Little ]

    I don't see any need to change from Txy to T:xy really

    Because it's unnecessarily complex to parse.

    The reason I mention it to you is because it's easier to have the
    flag translations built into the node translation that it would be
    to modify it later after native HRN software is already using Txy.

    No need. The idea is to get HRN used as the primary nodelist format
    used for distribution by the ZCs.

    Yeah, and? Eventually someone will write mail software that natively reads HRN, and then it will be too late to change the flags. The time to fix the flags is NOW, because the HRN->SLF converter can also convert the new flags back to the old ones. Simply: old software reads old flags and old nodelist format, new software reads new flags and new nodelist format.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to Rick Van Ruth on Mon Nov 11 11:07:37 2002
    [ 10 Nov 02 21:15, Rick Van Ruth wrote to Scott Little ]

    Couldn't that be done just via the organisation of the nodelist file?
    Or is that something that is being trying to be overcme?

    I assumed it was... perhaps not..


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to Rick Van Ruth on Mon Nov 11 11:08:35 2002
    [ 10 Nov 02 21:21, Rick Van Ruth wrote to Scott Little ]

    I can see you can have multiple "link" fields in yours, I assume a
    link line for each phone number or domain/ net address?

    Yep. Andrew's format uses a complete node records for each link type.

    Are there any other fields for the format?

    Like fields that currently don't have relevance to the St Louis
    format but are included in this format for future expansion?

    The FTSC can just issue new keywords as is required. Non-approved keywords should be prefixed with X- or something (like email headers) so they can be easily ignored, or at least treated like toxic waste.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Sat Nov 9 06:59:32 2002
    Hi andrew.

    05-Nov-02 20:46:16, andrew clarke wrote to Scott Little


    Tue 2002-11-05 17:54, Scott Little (3:712/848) wrote to andrew
    clarke:

    The hierachy is only important when it comes down to default
    mail routing, and politics. Parsing software should be able to
    handle

    >> Thing is, this format requires at least two scans of the nodelist
    >> to find a node and it's uplink. The only shortcut is to assume an
    >> uplink of /0 for normal nodes.

    Or one pass, then an in-memory search. I don't think this is a
    big problem.

    it is... code that does that may break as the nodelist grows... (wishful thinking I guess, but potentially borken code has caused problems in the
    past.) if you use database technology like a disk-based index (eg a B+ tree) then those probelms aren't.

    Bye <=-

    ---
    * Origin: Only adults have difficulty with childproof caps. (3:640/531.42)
  • From andrew clarke@3:633/267 to Frank Vest on Mon Nov 11 13:40:58 2002
    Sun 2002-11-10 15:40, Frank Vest (1:124/6308.1) wrote to andrew clarke:

    A new format should have an "order" and that "order", if adopted,
    would be the Hierarchy. IE:
    1:100/100
    1:101/100
    and so forth. The simple act of numerical order is a Hierarchy. :)

    But the HRN proposal I wrote currently allows for nodes to be listed randomly, with hierachy information (Parent) for each node to allow the human/software to
    find the true hierachy.

    So, if Fidonet is to keep the current Zone Region Net Node hierarchy,
    yes, we need that in the new format. If not, then no, we don't need
    it.

    Over Fido's dead body... I don't see it happening. ;-)

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
  • From Frank Vest@1:124/6308.1 to andrew clarke on Mon Nov 11 04:45:42 2002
    On (11 Nov 02) andrew clarke wrote to Frank Vest...

    Hello andrew,

    Sun 2002-11-10 15:40, Frank Vest (1:124/6308.1) wrote to andrew
    clarke:
    A new format should have an "order" and that "order", if adopted,
    would be the Hierarchy. IE:
    1:100/100
    1:101/100
    and so forth. The simple act of numerical order is a Hierarchy. :)

    But the HRN proposal I wrote currently allows for nodes to be listed randomly, with hierachy information (Parent) for each node to allow
    the human/software to find the true hierachy.

    I guess I'm an organizational freak. To me, human readable or not,
    there should be some form of order. Listing random order just seems
    wrong. Maybe it wouldn't matter to a program, but to me it does. :-)

    So, if Fidonet is to keep the current Zone Region Net Node hierarchy,
    yes, we need that in the new format. If not, then no, we don't need
    it.

    Over Fido's dead body... I don't see it happening. ;-)

    Agreed. It has also been argued that Fidonet could make do with one
    Zone and one Net. I don't see that happening either. ;)


    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 andrew clarke on Mon Nov 11 06:05:45 2002
    Hi andrew.

    10-Nov-02 01:30:42, andrew clarke wrote to Scott Little


    Wed 2002-11-06 09:16, Scott Little (3:712/848) wrote to andrew
    clarke:

    I couldn't find any ",T:" in my nodelist, so I think that's a
    non-issue, unless I've misunderstood.

    >> I mean, rather than Txx use T:xx so it's easier to parse.

    Well, firstly, that's something you should really take up with
    whoever wants to modify FTS-5001, ie. not me. Also Tyz is the
    format people are using in my current nodelist so presumably they
    aren't going see any reason to change. As for actually parsing
    it, it's seems simple enough to me - if the nodelist flag begins
    in T and contains non-alphabetic characters or isn't 3 characters
    long then it must be something else. But if it is a valid Tyz
    string then you just need a lookup table

    lookup table? it's a pretty simple formula for each character,
    for each character; this many minutes after midnight:

    30 * ((((c-'A') * 2) & 62)+((c-'A') & 32)/32)

    That's C but it's basically the same in pascal etc.

    Anyhow works ok how it is, it's just ugly. other flags have the name
    separated from the data.

    hmmm,

    I guess if the flags are defined (in the parser) to include the separator
    as part of the flag it could simplify programming without making Txx a
    special case.

    Bye <=-

    ---
    * Origin: Who's on first? (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 06:13:25 2002
    >> otherwise you make T a special case when parsing the nodelist and
    >> speaciual cases are yucky and tend to cause problems in the
    >> future,

    If the nodelist flag begins in T and contains non-alphabetic
    characters or isn't 3 characters long then it must be something
    else - right?

    yeah, that's exactly what I mean by a special case.

    I can use use a lookup table to resolve all the other flags, but the Txx ones need special treatment, (or an extre 2300 entrues in the lookup table)

    Bye <=-
    ---
    * Origin: 16 Km East of TV's "Croc Hunter" (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 06:26:37 2002
    Hi andrew.

    10-Nov-02 16:19:32, andrew clarke wrote to Scott Little


    Sun 2002-11-10 10:44, Scott Little (3:712/848) wrote to andrew
    clarke:

    >> St Louis and XML both enforce proper structure in the format
    >> itself, without relying on ignorable rules in the specification.
    >> (and eventually someone will try an alternate use for the Uplink,
    >> you watch)

    If there are rules in the spec, they can't be ignored!

    I don't see why that is... people ignore other rules in the current
    nodelist... I've seen hubs that were uncontactable... that sort of thing.

    I don't know what alternate use people would use for the Uplink
    keyword, but it won't matter, because the spec won't allow them
    to. And anyone using broken software that doesn't comply to the
    spec would be risking being denodelisted until they stop using it presumably

    you might think.

    Bye <=-

    ---
    * Origin: 16 Km East of TV's "Croc Hunter" (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to Rick Van Ruth on Mon Nov 11 06:38:50 2002
    Hi Rick.

    10-Nov-02 21:21:46, Rick Van Ruth wrote to Scott Little


    Hello Scott.

    10 Nov 02 20:52, you wrote to me:

    Then I guess I need to see a full example of the implementation.
    Got any?

    Erm, sorta. I generated a list using the routing address syntax
    (fugly, but it contains the full node hierarchy) to see what it
    would look like. Just pretend the keywords are to Andrew's specs
    instead... and ignore the blank keywords and other dodginess :)

    http://members.optushome.com.au/rtscts/rnl.zip

    Ok, I see.. but I still don't understand :-)

    I can see you can have multiple "link" fields in yours, I assume
    a link line for each phone number or domain/ net address?

    Are there any other fields for the format? Like fields that
    currently don't have relevance to the St Louis format but are
    included in this format for future expansion?

    It looks like the link feilds are more link records, each has provision for
    a fuill set of capability flags, so a multiline and/or multiprotocol system
    can list all it's connection methods and capabilities.

    Bye <=-

    ---
    * Origin: Paul's Law: You can't fall off the floor. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 06:44:35 2002
    Address 3:456/789
    Operating Dialup FTS-1 at 61-1-1234-5678,XA
    Online Sat 00:00-06:00

    I'm a point and my dialup mailer only does bink , not FTS-1 is there gpoing
    to be a flag for that? so I can determine which nodes do bink? :)

    Address 3:456/789
    Operating TCP/IP Binkp at 127.0.0.1
    Online Sun 00:00-06:00

    why repeat the address line?

    Bye <=-

    ---
    * Origin: Those who live in grass houses shouldn't throw flames (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 06:51:23 2002
    Hi andrew.

    >> Also what is the point of having "Parent"?

    To allow nodes to be listed in any order in the HRL.

    And your conversion software supports that?

    Bye <=-

    ---
    * Origin: Those who can't write, write manuals. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 18:56:44 2002
    The "Net" type is a synonym for "Host".
    The "Pvt" type is a synonym for "Private".
    The "Uplink" keyword is a synonym for "Parent".

    I don't like synonyms, they don't add anything but confusion, and work for programmers.

    This text may contain any alphanumeric or punctuation characters
    other than commas or underscores.

    I assume spaces are allowed in place of underscores
    what about characters above 127?

    Operating [Dialup] [FTS-1] [at] [phonenumber][,flags]

    Where [Dialup] is "Dialup" or "Dial-up", case neutral.

    Where [FTS-1] is "FTS-1" or "FTS1", case neutral.

    Where [at] is the word "at", and is case neutral and
    superfluous.

    Where [phonenumber] is in the format described by FTS-0005
    (or a superseding document).

    Where [,flags] is a comma-separated list of nodelist flags
    in the format described by FTS-0005 (or a superseding
    document).

    For nodes contactable via TCP/IP using the Binkp protocol,
    the following format is used:

    Operating [TCP/IP] [Binkp] [at] [host]

    no flags? why?

    Where [TCP/IP] is "TCP/IP" or "TCPIP" or "TCP" or "IP",
    case neutral.

    more synonyms... :(

    Online [text]

    The [text] following the optional Online keyword lists the times
    that the node is online. The format of the [text] field is:

    [day] [start time]-[end time]

    Where [day] specifies the day of the week when the node is online,
    and is a three letter English abbreviation for the day of the week,
    ie. Sun, Mon, Tue, Wed, Thu, Fri or Sat. [day] is case neutral.

    Where [start time] specifies the time when a node begins operation.

    Where [end time] specifies the time when a node ends operation.

    what if you're online from 23:00 to 01:00

    Times must be specified in 24-hour HH:MM format in UTC,

    day of week too :)

    Bye <=-

    ---
    * Origin: Bizarreness is the essence of the exotic (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Mon Nov 11 19:10:40 2002
    Hi andrew.

    I wanted to avoid long lines of text, because it tends to
    defeat the human-readable aspect

    make line breaks non-significant then. like in Pascal or C :)
    otoh you could overhaul the Txx flag to something like T:[0-6]*[a-xA-X][0-6]*[a-xA-x]

    where the [0-6]* represents an option group of digits which represent which days the online period stats as the time specified by the following letter,

    eg online 24hours (gmt) monday and friday only t:04AA

    or you can specify start and end days.

    eg: onlkine continuously from 7am monday to 5pm friday T:0F4Q

    compact, but not exaclty human readable.

    Is there a bif demand for this anyway? only a few nodes seem to use the existing txx flag.

    Bye <=-

    ---
    * Origin: If anything can go wrong, it will. (3:640/531.42)
  • From Scott Little@3:712/848 to Jasen Betts on Wed Nov 13 18:27:42 2002
    [ 11 Nov 02 18:56, Jasen Betts wrote to andrew clarke ]

    Where [TCP/IP] is "TCP/IP" or "TCPIP" or "TCP" or "IP",
    case neutral.
    more synonyms... :(

    Technically IP is more correct. I never liked "TCP/IP" since there's no rule TCP is involved at all...

    Where [start time] specifies the time when a node begins
    operation.
    Where [end time] specifies the time when a node ends
    operation.

    what if you're online from 23:00 to 01:00

    Would it be easier to implement if the start and duration were specified instead? Thu 23:00/2H, Fri 09:00/12H, etc.

    CM and ZMH should also die - each node should just list it's online time, whether or not it's required online time doesn't mean anything to a mailer, and
    means the mailer doesn't need to be configured with a lookup table for the ZMHs
    of each zone.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Jan Vermeulen@2:280/100 to Rick Van Ruth on Fri Nov 22 00:00:00 2002
    Quoting Rick Van Ruth on Sun 10 Nov 2002 18:41 to andrew clarke:

    I don't see any difference over the current listing method, the
    exact same information appears in your format with the only
    difference (except for "Parent") is that is is listed in lines
    and has the field names present.

    What advantage does this give?

    Also what is the point of having "Parent"?

    You wonder, I wonder, all wonder... no wonder ;-)

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Jasen Betts@3:640/531.42 to andrew clarke on Wed Nov 13 05:46:18 2002
    Hi andrew.

    11-Nov-02 03:43:38, andrew clarke wrote to Rick Van Ruth


    Sun 2002-11-10 23:19, Rick Van Ruth (3:640/954) wrote to andrew
    clarke:

    Operating Dialup FTS-1 at
    -Unpublished-,300,CM,XA,IBN:blizzard.dnsalias.org,IEM:mail@ozzmos
    is.com Operating TCP/IP BinkP at blizzard.dnsalias.org Contact
    E-mail mail@ozzmosis.com Contact Fax +61-3-9775-2610

    >> Why mention binkp twice? Just for backward compatability's sake?

    Yes.

    It seems to me that the new format may be easier to read but it also seems harder to write. (what I really mean is your new-to-old converter
    shouldn't need crutches like that)

    BTW what does your converter make of 1:267/200 :-)
    (this could be considered a trick question)

    Bye <=-

    ---
    * Origin: Confucius say too much. -- Recent Chinese Proverb (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to Scott Little on Wed Nov 13 05:58:32 2002
    Hi Scott.

    11-Nov-02 10:59:27, Scott Little wrote to andrew clarke


    [ 10 Nov 02 20:33, andrew clarke wrote to Scott Little ]

    I don't see any need to change from Txy to T:xy really

    Because it's unnecessarily complex to parse.

    The reason I mention it to you is because it's easier to have the
    flag translations built into the node translation that it would be
    to modify it later after native HRN software is already using Txy.

    No need. The idea is to get HRN used as the primary nodelist
    format used for distribution by the ZCs.

    Yeah, and? Eventually someone will write mail software that
    natively reads HRN, and then it will be too late to change the
    flags. The time to fix the flags is NOW, because the HRN->SLF
    converter can also convert the new flags back to the old ones.
    Simply: old software reads old flags and old nodelist format, new
    software reads new flags and new nodelist format

    The Tyz flag could dropped fron HRN being converted to online specifiers instead

    Bye <=-

    ---
    * Origin: A professor is one who talks in someone else's sleep. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to Scott Little on Sat Nov 23 21:44:53 2002
    Hi Scott.

    13-Nov-02 18:27:42, Scott Little wrote to Jasen Betts


    [ 11 Nov 02 18:56, Jasen Betts wrote to andrew clarke ]

    what if you're online from 23:00 to 01:00

    Would it be easier to implement if the start and duration were
    specified instead? Thu 23:00/2H, Fri 09:00/12H, etc

    that's a good idea.

    CM and ZMH should also die - each node should just list it's
    online time, whether or not it's required online time doesn't mean anything to a mailer, and means the mailer doesn't need to be
    configured with a lookup table for the ZMHs of each zone

    CM could remain as a synonym for "daily 00:00/24H", OTOH it could be the default... so yeah, it could be retired.





    Bye <=-

    ---
    * Origin: Positive: Mistaken at the top of one's voice. (3:640/531.42)
  • From Micael Bulow@2:204/710 to andrew clarke on Sat Dec 14 20:49:21 2002
    Okay, this is a bit old, but I just got the echo here so I'd like to give some oppinions on the subject:

    Human-readable (HR) nodelist format

    For simplicity and ease of use a human-readable (HR) ASCII text
    file format was chosen (in preference to, for example, CSV [Comma Separated Values] or XML [eXtensible Markup Language] formats). Of
    course this does not rule out the use of (or conversion to) these
    formats for future distribution of the FidoNet nodelist or segments thereof.

    This should be the other way around, if you ask me.

    The nodelist is to be distributed and read by machines, not humans. The base-format should be XML or similiar and then converted to human readable format when so required.

    It's my deepest belife that this should apply to all the standards within Fidonet.

    Otherwise we will still have the same problem as we do now to atract new developers, who is not used to bits and complecated rules of spaces and linefeeds.

    Besides this, you need addons and special utils if you want to store the nodelist data in another format (for example such as SQL). If you used XML as the base-format, you would not need any utils at all.

    Further on, the format will eventually be rewritten to XML in the future anyway, so we might aswell do it now. =)


    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Jan Vermeulen@2:280/100 to Micael Bulow on Sun Dec 15 00:00:00 2002
    Quoting Micael Bulow on Sat 14 Dec 2002 20:49 to andrew clarke:

    The nodelist is to be distributed and read by machines, not humans.

    Not quite:
    the nodelist is written by a large number of humans
    the nodelist is composed and distributed by machines
    the nodelist is read by humans and machines

    The base-format should be XML or similiar and then converted to human readable format when so required.

    The cost of transfer of ZIPped XML over phone lines is 1.23 times the cost of the same ZIPped file in ASCII style.

    It's my deepest belife that this should apply to all the standards
    within Fidonet.

    You will have understood that I beg to defer.

    Otherwise we will still have the same problem as we do now to atract
    new developers, who is not used to bits and complecated rules of
    spaces and linefeeds.

    Are you really saying that those developers are unable to write letters? I for me can not read something else in the phrase.

    Besides this, you need addons and special utils if you want to store
    the nodelist data in another format (for example such as SQL). If you
    used XML as the base-format, you would not need any utils at all.

    Now that is interesting: I can give the XML format to my mailer and it will
    work rightway, without any utilities?

    Further on, the format will eventually be rewritten to XML in the
    future anyway, so we might aswell do it now. =)

    Oh dear...

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Micael Bulow@2:204/710 to Jan Vermeulen on Mon Dec 16 02:45:11 2002
    The nodelist is to be distributed and read by machines, not humans.

    Not quite:
    the nodelist is read by humans and machines

    Are you reading the nodelist for brekfast, or what? =)

    The cost of transfer of ZIPped XML over phone lines is 1.23
    times the cost of the same ZIPped file in ASCII style.

    Yes, that's why we are applying an appropriate stylesheet for those who needs the old format.

    It is much harder to convert from the old format to XML then from XML to the old format since there is a standard XML parser in every modern programing language, script language and platform today.

    Otherwise we will still have the same problem as we do now to atract
    new developers, who is not used to bits and complecated rules of
    spaces and linefeeds.

    Are you really saying that those developers are unable to write letters? I for me can not read something else in the phrase.

    No, I'm saying that they wont do it since there is much more efficient techniques today.

    Now that is interesting: I can give the XML format to my mailer
    and it will work rightway, without any utilities?

    Surely you understand my point. If you don't, fine with me. If the rest of Fidonet agrees with you, thats also fine with me. I just wanted to give you my oppinion before the standards is set.

    We do have A LOT to gain in the future if we use a modern, widely known standard instead of the old ones that only a few people in Fidonet knows.

    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Jasen Betts@3:640/1042 to Micael Bulow on Tue Dec 17 17:14:27 2002
    Hi Micael.

    Otherwise we will still have the same problem as we do now to
    atract new developers, who is not used to bits and complecated
    rules of spaces and linefeeds.

    That's a good thing! if they can't handle a few simple formatting rules
    I'd be worried about the quality of their product.

    it's not like XML's going to be hassle-free either.

    Bye <=-

    ---
    * Origin: Dogs come when you call, cats have answering machines (3:640/1042)
  • From Jan Vermeulen@2:280/100 to Micael Bulow on Fri Dec 20 02:39:10 2002
    Quoting Micael Bulow on Mon 16 Dec 2002 2:45 to Jan Vermeulen:

    The nodelist is to be distributed and read by machines, not humans.

    Not quite:
    the nodelist is read by humans and machines

    Are you reading the nodelist for brekfast, or what? =)

    I have it for lunch on Friday and for dinner on Tuesday ;-))

    No kidding: I write part of the nodelist, every week. My part's title is REGION28.xxx.

    And I intend to continue to write it as I've always done, using a plain dos
    text editor.

    Why?

    First: because I'm good at it ;-)
    Second: because changes are easily made; moving a node from one
    hub to another takes no more than a few keystrokes and 2 seconds.
    Third: because file wide changes are a matter of less than seven
    keystrokes
    Fourth and most important: that's the way my ZC wants them

    The cost of transfer of ZIPped XML over phone lines is 1.23
    times the cost of the same ZIPped file in ASCII style.

    Yes, that's why we are applying an appropriate stylesheet for those
    who needs the old format.

    The current and not yet old format is needed by most, but that I have explained before and I hate to repeate myself.

    It is much harder to convert from the old format to XML then from
    XML to the old format since there is a standard XML parser in every
    modern programing language, script language and platform today.

    And you're incapable of writing a nodelist parser in order to obtain an XML
    database?


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From mark lewis@1:3634/12 to Jan Vermeulen on Thu Dec 19 21:51:08 2002
    No kidding: I write part of the nodelist, every week. My
    part's title is REGION28.xxx.

    oooooo... question for you...

    the PING and Tyz flags appear in the Z2 prolog _under_ the "approved user flags" heading... does this mean that they are only U,ser flags and not normal flags in Z2?

    i also note that the Z2 prolog doesn't state that the IEM flag is depricated like FTS-5001 states... i've not noted the IEM flag used in Z2 but do note the EMA flag appearing to be used in the same type vein as IEM...

    additionally, i personally note that V42B does not imply V42 capability... one is error correction and the other is data compression and neither relies on the
    other or implies the other... does Z2 view them differently? if so, why?

    FWIW: yes, i'm working on a nodelist analysis util...

    thanks!

    )\/(ark


    * Origin: (1:3634/12)
  • From Jan Vermeulen@2:280/100 to mark lewis on Sun Dec 22 00:12:03 2002
    Quoting mark lewis on Thu 19 Dec 2002 21:51 to Jan Vermeulen:

    oooooo... question for you...

    Let's see what help you can get from me...

    the PING and Tyz flags appear in the Z2 prolog _under_ the
    "approved user flags" heading... does this mean that they are only
    U,ser flags and not normal flags in Z2?

    The PING and Tyz flags appear in the Z2 prolog:
    _below_ the "user flag" definition
    but _above_ the "approved user flags" heading

    Thusly they're not user flags.

    That was an easy one, was it not?

    i also note that the Z2 prolog doesn't state that the IEM flag is depricated like FTS-5001 states... i've not noted the IEM flag used
    in Z2 but do note the EMA flag appearing to be used in the same
    type vein as IEM...

    Z2 has nearly one hundred IEM flags flying, even the ZC himself. If you have a problem with that, please ask Ward.

    additionally, i personally note that V42B does not imply V42
    capability... one is error correction and the other is data
    compression and neither relies on the other or implies the other...
    does Z2 view them differently? if so, why?

    As far as I know, that relation has been in the nodelist for at least 10 years so I assume there is a good reson for that.

    Maybe because modems were marketed that way?

    FWIW: yes, i'm working on a nodelist analysis util...

    With what purpose beyond fun?

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From mark lewis@1:3634/12 to Jan Vermeulen on Thu Dec 26 15:45:00 2002
    Quoting mark lewis on Thu 19 Dec 2002 21:51 to Jan
    Vermeulen:

    oooooo... question for you...

    Let's see what help you can get from me...

    the PING and Tyz flags appear in the Z2 prolog _under_ the
    "approved user flags" heading... does this mean that they are only U,ser flags and not normal flags in Z2?

    The PING and Tyz flags appear in the Z2 prolog:
    _below_ the "user flag" definition
    but _above_ the "approved user flags" heading

    Thusly they're not user flags.

    hummm... reading what you've written, it would appear that they /are/ userflags... just not _approved_ userflags...

    That was an easy one, was it not?

    seems that way... just looking for confirmation and information...

    i also note that the Z2 prolog doesn't state that the IEM flag is depricated like FTS-5001 states... i've not noted the IEM flag used
    in Z2 but do note the EMA flag appearing to be used in the same
    type vein as IEM...

    Z2 has nearly one hundred IEM flags flying, even the ZC
    himself. If you have a problem with that, please ask Ward.

    not a problem... what i was noting is that EMS shows up in my "error" reports... those IEM flags must be "properly" implemented in so far as my util currently checks for them...

    additionally, i personally note that V42B does not imply V42 capability... one is error correction and the other is data compression and neither relies on the other or implies the other... does Z2 view them differently? if so, why?

    As far as I know, that relation has been in the
    nodelist for at least 10 years so I assume there is a good
    reson for that.

    Maybe because modems were marketed that way?

    v42 and v42b are protocols... like v90 and mnp and exactly that way... one is data compression and the other is error correction... the specs for each do not define the other as necessary or a mandated fallback capability...

    from what i've seen over all these years, they got "grouped" together simply because the ITU-T (can't remember their original name) used 42 in both of them and the average layman wasn't able to tell that they weren't related...

    FWIW: yes, i'm working on a nodelist analysis util...

    With what purpose beyond fun?

    to look at "strict adherence to the published specs" concerning the nodelist format and flags used in it...

    )\/(ark


    * Origin: (1:3634/12)
  • From Jan Vermeulen@2:280/100 to mark lewis on Fri Dec 27 19:00:58 2002
    Quoting mark lewis on Thu 26 Dec 2002 15:45 to Jan Vermeulen:

    The PING and Tyz flags appear in the Z2 prolog:
    _below_ the "user flag" definition
    but _above_ the "approved user flags" heading

    Thusly they're not user flags.

    hummm... reading what you've written, it would appear that they
    /are/ userflags... just not _approved_ userflags...

    How likely do you think yourself it would be for the IC to allow _non_approved_ flags of any kind to appear as allowed in his own epilog.txt?

    Use a scale of 1 bit ;-)

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From mark lewis@1:3634/12 to Jan Vermeulen on Fri Dec 27 16:32:32 2002
    The PING and Tyz flags appear in the Z2 prolog:
    _below_ the "user flag" definition
    but _above_ the "approved user flags" heading

    Thusly they're not user flags.

    hummm... reading what you've written, it would appear that they
    /are/ userflags... just not _approved_ userflags...

    How likely do you think yourself it would be for the IC to
    allow _non_approved_ flags of any kind to appear as allowed in
    his own epilog.txt?

    Use a scale of 1 bit ;-)

    hahaha, yeah, i see what you are saying... however, that's almost totally rediculous because that is exactly what userflags were created for ;-) i know
    that some software i beta test for may not want to have to go thru some "approval methods" to be able to test a new flag proposal... especially if those "approval methods" are as "time consuming" as the recent P4 updates appear to be... that would kill that software in no time flat...

    )\/(ark


    * Origin: (1:3634/12)
  • From Jan Vermeulen@2:280/100 to mark lewis on Sat Dec 28 18:42:04 2002
    Quoting mark lewis on Fri 27 Dec 2002 16:32 to Jan Vermeulen:

    hahaha, yeah, i see what you are saying... however, that's almost
    totally rediculous because that is exactly what userflags were
    created for ;-)

    Have they? I really don't remember. I'll have to dig in a very dusty archive to find a paper on the subject I know I should have.

    i know that some software i beta test for may not want to have to go
    thru some "approval methods" to be able to test a new flag proposal

    Temporary approvals have been used in Z2 to test such flags ;-)

    ... especially if those "approval methods" are as "time consuming"
    as the recent P4 updates appear to be... that would kill that
    software in no time flat...

    I fail to see the connection.

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From mark lewis@1:3634/12 to Jan Vermeulen on Sun Dec 29 20:09:56 2002
    hahaha, yeah, i see what you are saying... however, that's almost
    totally rediculous because that is exactly what userflags were
    created for ;-)

    Have they? I really don't remember. I'll have to dig in a
    very dusty archive to find a paper on the subject I know I
    should have.

    i'd be interested in that info when you locate it...

    i know that some software i beta test for may not want to have to go
    thru some "approval methods" to be able to test a new flag proposal

    Temporary approvals have been used in Z2 to test such
    flags ;-)

    possibly... but in the old days, it was generally enough to ask one's NC to add
    the flag...

    ... especially if those "approval methods" are as "time consuming"
    as the recent P4 updates appear to be... that would kill that
    software in no time flat...

    I fail to see the connection.

    there's been a proposal to modify P4 on the table for over a years... someone is (still) sitting on it...

    )\/(ark


    * Origin: (1:3634/12)
  • From Micael Bulow@2:204/710 to Jan Vermeulen on Sat Jan 4 05:38:32 2003
    No kidding: I write part of the nodelist, every week. My part's
    title is REGION28.xxx.
    And I intend to continue to write it as I've always done, using
    a plain dos text editor.

    That would be no problem. You could still do that with XML.

    The current and not yet old format is needed by most, but that

    Yes. Today. Not tomorrow.

    And you're incapable of writing a nodelist parser in order to
    obtain an XML database?

    Your'e missing the point.

    But, judgeing by the latest weeks of discussions, the rest of the community seem to want an old comma-demelited textfile eaven in the future, so I think we
    can put this battle on hold (for now). :-)

    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Jan Vermeulen@2:280/100 to Micael Bulow on Sat Jan 4 15:39:00 2003
    Quoting Micael Bulow on Sat 4 Jan 2003 5:38 to Jan Vermeulen:

    And I intend to continue to write it as I've always done, using
    a plain dos text editor.

    That would be no problem. You could still do that with XML.

    Really?

    - Move an entire line from one hub to the next
    - Duplicate a line, change the node number and the phone number on
    that line
    - Do a general search and controlled replace on the entire file

    Just to name a few of what I've done during the last month...

    [...]

    And you're incapable of writing a nodelist parser in order to
    obtain an XML database?

    Your'e missing the point.

    Not impossible, but have you checked your explanations?

    But, judgeing by the latest weeks of discussions, the rest of the community seem to want an old comma-demelited textfile eaven in the future, so I think we can put this battle on hold (for now). :-)

    It is always wise to lean back and reflect for some time ;-))


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Micael Bulow@2:204/710 to Jan Vermeulen on Sat Jan 4 18:24:51 2003
    And I intend to continue to write it as I've always done,
    using
    a plain dos text editor.

    That would be no problem. You could still do that with XML.

    Really?

    - Move an entire line from one hub to the next
    - Duplicate a line, change the node number and the phone number on
    that line
    - Do a general search and controlled replace on the entire file

    All of that can be done with an XML file. XML is plain text.


    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Jan Vermeulen@2:280/100 to Micael Bulow on Sat Jan 4 21:51:48 2003
    Quoting Micael Bulow on Sat 4 Jan 2003 18:24 to Jan Vermeulen:

    All of that can be done with an XML file. XML is plain text.

    So please show us the following lines in XML:

    Hub,60,Netherlands_Hub_60,Wormerveer,Jan_Vermeulen,31-75-6400418,
    9600,CM,XA,V32B,V42B,V34,VFC,V120L,V120H,X75,PING,IBN:213.84.
    184.65,U,ENC ,100,213.84.184.65,Wormerveer,Jan_Vermeulen,31-75-6400418,9600,CM
    ,XA,V32B,V42B,V34,VFC,V120L,V120H,X75,IBN,PING,U,ENC ,309,WolfSoft,Amsterdam,Michiel_Wolvetang,31-20-6097080,9600,MO,X
    A,HST,V32T,VFC,V34,X75 ,1010,Overal_Den_Daar_Den,Hierden,Harm_Hop,31-341-453919,9600,V42
    B,V34,MO,XA ,1046,Lonely_Nights,Amersfoort,Peter_Looyenga,31-33-4756435,9600,
    XA,CM,V32B,V42B,V34,U,ENC ,1049,The_Coast,Ouddorp,Simon_Voortman,31-187-683942,9600,CM,XA,V
    32B,V42B,V34 ,1099,Concerto-BBS,Capelle_a/d_IJssel,Wim_Louwerse,31-10-2847713,
    9600,CM,XA,V32B,V42B,VFC,V34,X75 ,1203,BBS_De_Randstad,Den_Haag,Frank_de_Bruijn,31-70-3557975,9600
    ,CM,XX,V32B,V42B,V34 ,4312,snake.ath.cx,Maastricht,Jos_Huijnen,31-43-3540992,9600,CM,M
    O,XA,VFC,V90C,X75,IBN,IMI,ISE,ITX,IUC,IEM:mailtunnel@snake.at
    h.cx,PING,U,ENC

    All lines truncated after pos 65 and resumed at pos 5.


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Scott Little@3:712/848 to Jan Vermeulen on Sun Jan 5 08:52:25 2003
    [ 04 Jan 03 21:51, Jan Vermeulen wrote to Micael Bulow ]

    So please show us the following lines in XML:

    The structure is still being considered.. that's the tricky bit. If we knew how to arrange the data we'd be writing code right now.


    <hub number="60" name="Netherlands Hub 60" sysop="Jan Vermeulen">
    <user-flags />PING, ENC
    <link type="PSTN" number="31-75-6400-418" flags="CM,XA,V32B,V42B,V34,VFC"

    <link type="ISDN" number="31-75-6400-418" flags="CM,XA,V120L,V120H,X75" />
    <link type="IP" address="213.84.184.65" flags="IBN" />

    <node number="100">
    <name />213.84.184.65
    <sysop />Jan Vermeulen
    <user-flags />CM, PING, ENC

    <link class="DIALUP">
    <number />31-75-6400-418
    <flags />XA,V32B,V42B,V34,VFC,V120L,V120H,X75
    </link>

    <link type="IP">
    <address />213.84.184.65
    <flags />IBN
    </link>
    </node>

    <node number="309" foo="bar">
    <comment />and so on and so forth...
    </node>

    </hub>


    That's just two possible ways of listing the same node (60 and 100 have the same data, except their name) - using attributes of an element (name= sysop= flags= etc), and using sub-elements (<name> <flags> etc), and just one way of nesting the addressing structure (Nodes as sub elements of a Hub, rather than as attributes of the nodes).


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Janis Kracht@1:261/38 to Scott Little on Sat Jan 4 19:50:18 2003
    Hello Scott,

    I thought all xml had to be prefaced with another document...

    [ 04 Jan 03 21:51, Jan Vermeulen wrote to Micael Bulow ]

    So please show us the following lines in XML:

    The structure is still being considered.. that's the tricky bit. If we knew how to arrange the data we'd be writing code right now.
    [...]

    Take care,
    Janis

    --- BBBS/LiI v4.01 Flag-4
    * Origin: Prism bbs (1:261/38)
  • From Scott Little@3:712/848 to Janis Kracht on Sun Jan 5 12:22:58 2003
    [ 04 Jan 03 19:50, Janis Kracht wrote to Scott Little ]

    I thought all xml had to be prefaced with another document...

    No idea.. they usually have the xml version and sometimes a DTD or other bits at the top before the main content, but I don't know if it's necessary.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Micael Bulow@2:204/710 to Jan Vermeulen on Sun Jan 5 03:55:56 2003
    So please show us the following lines in XML:

    C'mon.. :-)

    I'll give ju an example that comes from my uplink. The compleate nodelist can be found here: http://voyager.datapartner.se/xml/nodelist.xml and it's just a test, so dont worry. :-)

    <?xml version="1.0" encoding="UTF-8" ?>
    <!-- XML Nodelist - use for testing only! -->
    <!-- Copyright yadda yadda -->
    <nodelist version="Friday, December 6, 2002 -- Day number 340">
    <domain name="fidonet">
    <zone number="2">
    <zc>
    <number>2</number>
    <system>Europe (340)</system>
    <location>Belgium</location>
    <sysop>Ward Dossche</sysop>
    <phone>32-3-4480880</phone>
    <bps>33600</bps>
    <flag>V34</flag>
    <flag>VFC</flag>
    <flag>CM</flag>
    <flag>XX</flag>
    <flag>IEM</flag>
    <flag>ITX</flag>
    <flag>IBN</flag>
    </zc>
    <node>
    <number>1</number>
    <system>ZoneGate Eur NorthAm</system>
    <location>BE</location>
    <sysop>Ward Dossche</sysop>
    <phone>32-3-4480880</phone>
    <bps>33600</bps>
    <flag>V34</flag>
    <flag>VFC</flag>
    <flag>CM</flag>
    <flag>XX</flag>
    </node>
    <node>
    [....]
    </node>
    </zone>
    </domain>
    </nodelist>


    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Micael Bulow@2:204/710 to Scott Little on Sun Jan 5 04:12:53 2003
    I thought all xml had to be prefaced with another document...

    No idea.. they usually have the xml version and sometimes a DTD or
    other bits at the top before the main content, but I don't know if
    it's necessary.

    It's optional.

    We should, however, keep an accurate schema for thoose who whish to check calidity against it ant to keep a structure for developers.

    //Micke
    ---
    * Origin: OX12.NET (2:204/710)
  • From Janis Kracht@1:261/38 to Scott Little on Sun Jan 5 00:32:30 2003
    Hello Scott,

    I thought all xml had to be prefaced with another document...

    No idea.. they usually have the xml version and sometimes a DTD or other bits at the top before the main content, but I don't know if it's necessary.

    hahaha :) It's necessary if you want to validate the document :)

    Take care,
    Janis

    --- BBBS/LiI v4.01 Flag-4
    * Origin: Prism bbs (1:261/38)
  • From Jan Vermeulen@2:280/100 to Scott Little on Sun Jan 5 18:49:54 2003
    Quoting Scott Little on Sun 5 Jan 2003 8:52 to Jan Vermeulen:

    [ 04 Jan 03 21:51, Jan Vermeulen wrote to Micael Bulow ]

    So please show us the following lines in XML:

    The structure is still being considered.. that's the tricky bit.
    If we knew how to arrange the data we'd be writing code right now.

    Having seen what followed I can see that...

    A few comments:

    <hub number="60" name="Netherlands Hub 60" sysop="Jan Vermeulen">
    <user-flags />PING, ENC

    PING is not a User Flag.

    <link type="PSTN" number="31-75-6400-418"
    flags="CM,XA,V32B,V42B,V34,VFC" />
    <link type="ISDN" number="31-75-6400-418"
    flags="CM,XA,V120L,V120H,X75" />
    <link type="IP" address="213.84.184.65" f
    lags="IBN" />

    311 characters where the nodelist uses 143. 217%...

    <node number="100">
    <name />213.84.184.65
    <sysop />Jan Vermeulen
    <user-flags />CM, PING, ENC

    CM and PING are not user flags...

    <link class="DIALUP">
    <number />31-75-6400-418
    <flags />XA,V32B,V42B,V34,VFC,V120L,V120H,X75
    </link>

    <link type="IP">
    <address />213.84.184.65
    <flags />IBN
    </link>
    </node>

    377 characters for 117 in the nodelist: 322%

    </hub>

    That's just two possible ways of listing the same node (60 and 100
    have the same data, except their name) - using attributes of an
    element (name= sysop= flags= etc), and using sub-elements (<name>
    <flags> etc), and just one way of nesting the addressing structure
    (Nodes as sub elements of a Hub, rather than as attributes of the
    nodes).

    Either way, it takes a lot more screen and a lot more typing for *Cs that are supposed to keep their part of the nodelist up to date.

    Parsing by a mailer will take considerably more time, wether it builds its own database or uses the XML file instead of the GONL (Good Old NodeList).

    The size of the uncompressed XML nodelist will be about 275% of the GONL; your compression ratio will be better becayse of the many spaces so you may end
    up with a zip file size of 135%.

    You're worse off as soon as you start adding charcters over 0x7F and follow
    the UT-8 or even UNICODE rules.

    Do not think I am your enemy; I evaluate this project the same way was in my professial life.


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Jan Vermeulen@2:280/100 to Micael Bulow on Sun Jan 5 18:53:56 2003
    Quoting Micael Bulow on Sun 5 Jan 2003 3:55 to Jan Vermeulen:

    So please show us the following lines in XML:

    C'mon.. :-)

    I'll give ju an example that comes from my uplink. The compleate
    nodelist can be found here: http: //voyager.datapartner.se/xml/nodelist.xml and it's just a test, so
    dont worry. :-)

    I never worry.

    Lets see what we got here:

    <?xml version="1.0" encoding="UTF-8" ?>
    <!-- XML Nodelist - use for testing only! -->
    <!-- Copyright yadda yadda -->
    <nodelist version="Friday, December 6, 2002 -- Day number 340">
    <domain name="fidonet">
    <zone number="2">
    <zc>
    <number>2</number>
    <system>Europe (340)</system>
    <location>Belgium</location>
    <sysop>Ward Dossche</sysop>
    <phone>32-3-4480880</phone>
    <bps>33600</bps>
    <flag>V34</flag>
    <flag>VFC</flag>
    <flag>CM</flag>
    <flag>XX</flag>
    <flag>IEM</flag>
    <flag>ITX</flag>
    <flag>IBN</flag>
    </zc>
    <node>
    <number>1</number>
    <system>ZoneGate Eur NorthAm</system>
    <location>BE</location>
    <sysop>Ward Dossche</sysop>
    <phone>32-3-4480880</phone>
    <bps>33600</bps>
    <flag>V34</flag>
    <flag>VFC</flag>
    <flag>CM</flag>
    <flag>XX</flag>
    </node>
    <node>
    [....]
    </node>
    </zone>
    </domain>
    </nodelist>


    Oh man, all those spaces. I do get the willies 8)

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From andrew clarke@3:633/267.1 to Jan Vermeulen on Mon Jan 6 05:40:06 2003
    Sun 2003-01-05 18:49, Jan Vermeulen (2:280/100) wrote to Scott Little:

    <link type="IP">
    <address />213.84.184.65
    <flags />IBN
    </link>
    </node>

    Either way, it takes a lot more screen and a lot more typing for
    *Cs that are supposed to keep their part of the nodelist up to date.

    This is probably the only remaining thing that turns me off the idea of an XML nodelist. People shouldn't need to edit it by hand - it'll frighten them away.
    But I understand there are numerous GUI XML editors floating around. I don't know if any do validation though, or how the validation process (ie. syntax-checking the XML) actually works in reality. Scott?

    Parsing by a mailer will take considerably more time, wether it
    builds its own database or uses the XML file instead of the GONL (Good
    Old NodeList).

    The size of the uncompressed XML nodelist will be about 275% of the GONL; your compression ratio will be better becayse of the many spaces
    so you may end up with a zip file size of 135%.

    You're worse off as soon as you start adding charcters over 0x7F
    and follow the UT-8 or even UNICODE rules.

    Not a big problem. Anyone really bothered by the size and extra processing time can keep using SLF.

    -- mail@ozzmosis.com

    --- Msged/NT 6.1.1
    * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267.1)
  • From Scott Little@3:712/848 to Jan Vermeulen on Mon Jan 6 07:20:27 2003
    [ 05 Jan 03 18:49, Jan Vermeulen wrote to Scott Little ]

    Forgive me if I'm a little harsh, but...

    311 characters where the nodelist uses 143. 217%...
    [snip]
    377 characters for 117 in the nodelist: 322%

    Stupid arguement.

    Either way, it takes a lot more screen and a lot more typing for
    *Cs that are supposed to keep their part of the nodelist up to date.

    Stupid arguement.

    Parsing by a mailer will take considerably more time, wether it
    builds its own database or uses the XML file instead of the GONL (Good
    Old NodeList).

    Stupid arguement.

    The size of the uncompressed XML nodelist will be about 275% of
    the GONL; your compression ratio will be better becayse of the many
    spaces so you may end up with a zip file size of 135%.

    Stupid arguement.

    You're worse off as soon as you start adding charcters over 0x7F
    and follow the UT-8 or even UNICODE rules.

    Stupid arguement.


    You seem to have a problem understanding that XML or any other new format is not just a rearrangement of the old one. You're expecting something for nothing, and it's not going to happen. A new format has "MORE FEATURES, MORE EASY, MORE SHINY!" and it's going to get bigger as a result. *This is the desired outcome* If you don't like it, then stay with SLF and all it's limitations.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Scott Little@3:712/848 to andrew clarke on Mon Jan 6 07:46:58 2003
    [ 06 Jan 03 05:40, andrew clarke wrote to Jan Vermeulen ]

    I don't know if any do validation though, or how the validation
    process (ie. syntax-checking the XML) actually works in reality.
    Scott?

    "Legal" XML simply means that all tags are properly terminated, etc. and most good XML libraries support DTDs and/or Schemas which check the structure and data for compliance with user defined (ie. FTSC or *C issued) specs. Any segment processor that is capable of rejecting bad incoming segments will be able to manually check local segments after modification and before getting sent upsteam.

    Given the availability of XML libraries, it probably won't be too out of the question for a dedicated XML Nodelist editor to be written somewhere along the line, rather than rely on generic XML editors.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Jan Vermeulen@2:280/100 to Scott Little on Mon Jan 6 01:58:56 2003
    Quoting Scott Little on Mon 6 Jan 2003 7:20 to Jan Vermeulen:

    Stupid arguement.

    Stupid arguement.

    Stupid arguement.

    Stupid arguement.

    Stupid arguement.

    I must have had one of these off days. Sorry for that.

    You seem to have a problem understanding that XML or any other new
    format is not just a rearrangement of the old one. You're
    expecting something for nothing, and it's not going to happen. A
    new format has "MORE FEATURES, MORE EASY, MORE SHINY!" and it's
    going to get bigger as a result. *This is the desired outcome* If
    you don't like it, then stay with SLF and all it's limitations.

    I may still have my off day, 'coz I did not see any new features, no more ease and my screen is still as dull as it was before. All I saw was more room for the same data.

    In another posting I have explainend what logistic problems can be expected
    from the dual nodelist project you propose.

    I would have liked it to be different and thus I will continue to find ways
    of improvement, step by step in order not to break the net.


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Scott Little@3:712/848 to Jan Vermeulen on Mon Jan 6 16:56:01 2003
    [ 06 Jan 03 01:58, Jan Vermeulen wrote to Scott Little ]

    I must have had one of these off days. Sorry for that.

    Wrong arguements for the wrong crowd..

    I may still have my off day, 'coz I did not see any new features,
    no more ease and my screen is still as dull as it was before. All I
    saw was more room for the same data.

    Because you said "convert this" so you were given some demos...

    In another posting I have explainend what logistic problems can be expected from the dual nodelist project you propose.

    I expect that to be more of a problem (if any) in your zone than the rest...

    I would have liked it to be different and thus I will continue to
    find ways of improvement, step by step in order not to break the net.

    Perhaps you can outline your vision for step by step improvement, without making the nodelist bigger, without making it incompatible with existing nodes,
    and all your other beefs.. ?


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Peter Knapper@3:772/1.10 to Scott Little on Mon Jan 6 21:18:04 2003
    Hi Scott,

    "Legal" XML simply means that all tags are properly
    terminated, etc. and most good XML libraries support
    DTDs and/or Schemas which check the structure and data
    for compliance with user defined (ie. FTSC or *C
    issued) specs.

    As an XML illiterate here, if I read what you wrote above correctly, are you suggesting that it may be possible to construct an XML Nodelist segment "assembly" tool, using only source data files, XML "definition" files and a "standard" XML processing engine to interpret and action those definitions and data files? IE we dont necessarily need a standalone utility, just each person wishing to work with XML would just need the "engine" component (plus definition files) for their particular OS? Would suchan environment be able to handle all the functionality that Fidonet would require, or external code still
    required?

    If so, can you suggest such an engine for OS/2?......;-)


    Given the availability of XML libraries, it probably
    won't be too out of the question for a dedicated XML
    Nodelist editor to be written somewhere along the line,
    rather than rely on generic XML editors.

    Does XML include the capabilty to define this sort of operation (IE creating and editor) within the definition files themselves?

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

    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Scott Little@3:712/848 to Peter Knapper on Tue Jan 7 03:52:28 2003
    [ 06 Jan 03 21:18, Peter Knapper wrote to Scott Little ]

    As an XML illiterate here, if I read what you wrote above correctly,
    are you suggesting that it may be possible to construct an XML
    Nodelist segment "assembly" tool, using only source data files, XML "definition" files and a "standard" XML processing engine to interpret
    and action those definitions and data files?

    Hmm.. you can use generic tools to create a segment and/or check it for legality and compliance with a certain format, you may even be able to merge XML segments with a generic tool (a simple overlay algorithm), but you'll need a custom tool to accept incoming segments, apply a header or something, and send outgoing segments.

    If so, can you suggest such an engine for OS/2?......;-)

    If I ever get around to it.. whatever I write will most likely be in Python, so
    install Python/2 and you're golden :)

    Given the availability of XML libraries, it probably
    won't be too out of the question for a dedicated XML
    Nodelist editor to be written somewhere along the line,
    rather than rely on generic XML editors.

    Does XML include the capabilty to define this sort of operation (IE creating and editor) within the definition files themselves?

    Umm.. wot? I suppose a very good XML editor could use a def to construct appropriate input templates, but I don't know of any that do that. If that's what you meant.. ?


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)
  • From Jan Vermeulen@2:280/100 to Scott Little on Mon Jan 6 21:45:56 2003
    Quoting Scott Little on Mon 6 Jan 2003 16:56 to Jan Vermeulen:

    I may still have my off day, 'coz I did not see any new features,
    no more ease and my screen is still as dull as it was before. All I
    saw was more room for the same data.

    Because you said "convert this" so you were given some demos...

    And the result was a flood of additional characters and empty space...

    In another posting I have explainend what logistic problems can be
    expected from the dual nodelist project you propose.

    I expect that to be more of a problem (if any) in your zone than
    the rest...

    Could well be so, with over 75% of the Fidonet population.

    I would have liked it to be different and thus I will continue to
    find ways of improvement, step by step in order not to break the net.

    Perhaps you can outline your vision for step by step improvement...

    I'm working on that.

    without making the nodelist bigger,

    The evarage increase per /affected/ node should not be more than 15%, probably much less in those cases were a few caracters would suffice.

    without making it incompatible with existing nodes...

    Assuring that will take a lot of care and require additional steps to be made.

    ... and all your other beefs.. ?

    How would you know that I'm not a vegaterian who would take offence from this expression?


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Peter Knapper@3:772/1.10 to Scott Little on Tue Jan 7 17:57:18 2003
    Hi Scott,

    If so, can you suggest such an engine for OS/2?......;-)

    If I ever get around to it.. whatever I write will most
    likely be in Python, so install Python/2 and you're golden :)

    I actually grabbed a copy of Python/2 but never felt the need to instal it. I may have a re-think about that now.....;-)

    Does XML include the capabilty to define this sort of operation (IE creating and editor) within the definition files themselves?

    Umm.. wot? I suppose a very good XML editor could use
    a def to construct appropriate input templates, but I
    don't know of any that do that. If that's what you meant.. ?

    It sounds like what I was tryig to say.

    Darn, I may need to look into this a bit more.....;-(

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Scott Little@3:712/848 to Jan Vermeulen on Tue Jan 7 19:17:08 2003
    [ 06 Jan 03 21:45, Jan Vermeulen wrote to Scott Little ]

    ... and all your other beefs.. ?
    How would you know that I'm not a vegaterian who would take
    offence from this expression?

    If you are, let me say this: for every animal you don't eat, I WILL EAT THREE!!

    Muhahahaha

    I take no small amount of pleasure in toying with veggies, greenies and the various morals crusaders.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- FMail/Win32 1.60+
    * Origin: Cyberia: All your msgbase are belong to us! (3:712/848)