Human-readable (HR) distribution nodelist
Operating [text]
Online [text]
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).
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
keyword defines the address of a node in the nodelist. Point
addresses are not permitted. Each time an Address line appears in
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.
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.
<end brainstorm session>
<makes note to switch to decaf>
This allows specifying (but not overriding existing) missing
hierarchy* pieces that aren't part of the address (all of it for St.
(domains, regions) with back referencing information (end nodes
specify their zones and nets).
Fri 2002-11-01 03:44, andrew clarke (3:633/285.4) wrote to All:
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.
Bye <=-
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.
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.
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
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...
The hierachy is only important when it comes down to default mail
routing, and politics. Parsing software should be able to handle
Probably a good idea. I think nodelist segments (and diffs) should probably be the subject of another document though
and Password keywords can be described in terms of segment processing software and not in terms of the entire nodelist, because it would
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.
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.
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 I should add to the current spec that "keywords in the nodelist
that are not recognised should be ignored"
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.
There should be no technical limit to the number of peers allowed,
Bye <=-
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.
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...
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 couldn't find any ",T:" in my nodelist, so I think that's a
non-issue, unless I've misunderstood.
Admittedly it is longer, but it IS human readable. :-)
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
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 :(
diff -n ?
[ 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
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
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"
Bye <=-
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
Bye <=-
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.
Bye <=-
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.
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.
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.
I had a look at the nodelist it generated, but sorry I don't agree
with the fields
I had a look at the nodelist it generated, but sorry I don't agree
with the fields
Feel free to share specifics..
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 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?)
I don't think you can, because FTS-5001 has made it a standard. And
you can't change standards, only add to them.
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!)
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.
I don't understand why some information is given a line for the field
yet the connection information is still all in one line.
Fully specifying the address for each node bothers me, esp. inWhy?
conjunction with the Uplink field.
You can only extend the standard or obsolete it.
If there are rules in the spec, they can't be ignored!
You just can't do that. ;-)
I don't know what alternate use people would use for the Uplink
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 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 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
Also what is the point of having "Parent"?
Then I guess I need to see a full example of the implementation.
Got any?
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.
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...
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.
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
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!
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...
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...
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
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"?
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: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
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?
What do others think? Should a new nodelist format list nodes in hierachical order like the St Louis format does? And why. ;-)
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.
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.
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.
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)
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.
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.
(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]
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.
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.
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>
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.
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
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. ;-)
I don't see any need to change from Txy to T:xy really
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.
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 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?
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
Or one pass, then an in-memory search. I don't think this is a
big problem.
Bye <=-
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.
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. ;-)
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.
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
Bye <=-
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?
Bye <=----
Sun 2002-11-10 10:44, Scott Little (3:712/848) wrote to andrew
clarke:
If there are rules in the spec, they can't be ignored!
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
Bye <=-
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?
Bye <=-
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
Bye <=-
To allow nodes to be listed in any order in the HRL.
Bye <=-
The "Net" type is a synonym for "Host".
The "Pvt" type is a synonym for "Private".
The "Uplink" keyword is a synonym for "Parent".
This text may contain any alphanumeric or punctuation characters
other than commas or underscores.
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.
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,
Bye <=-
I wanted to avoid long lines of text, because it tends to
defeat the human-readable aspect
Bye <=-
Where [TCP/IP] is "TCP/IP" or "TCPIP" or "TCP" or "IP",more synonyms... :(
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
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"?
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
Yes.
Bye <=-
[ 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
Bye <=-
[ 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
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
Bye <=-
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.
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. =)
The nodelist is to be distributed and read by machines, not humans.
Not quite:
the nodelist is read by humans and machines
The cost of transfer of ZIPped XML over phone lines is 1.23
times the cost of the same ZIPped file in ASCII style.
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.
Now that is interesting: I can give the XML format to my mailer
and it will work rightway, without any utilities?
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.
Bye <=-
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.
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...
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?
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...
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...
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.
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.
The current and not yet old format is needed by most, but that
And you're incapable of writing a nodelist parser in order to
obtain an XML database?
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.
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). :-)
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.
So please show us the following lines in XML:
[ 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.
I thought all xml had to be prefaced with another document...
So please show us the following lines in XML:
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.
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.
[ 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" f
lags="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>
</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).
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>
<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.
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.
311 characters where the nodelist uses 143. 217%...[snip]
377 characters for 117 in the nodelist: 322%
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.
I don't know if any do validation though, or how the validation
process (ie. syntax-checking the XML) actually works in reality.
Scott?
Stupid arguement.
Stupid arguement.
Stupid arguement.
Stupid arguement.
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.
I must have had one of these off days. Sorry for that.
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.
"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.
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.
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?
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?
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.. ?
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 :)
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.. ?
... and all your other beefs.. ?How would you know that I'm not a vegaterian who would take
offence from this expression?
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,030 |
| Nodes: | 17 (0 / 17) |
| Uptime: | 03:15:53 |
| Calls: | 503,586 |
| Files: | 136,306 |
| D/L today: |
3 files (340K bytes) |
| Messages: | 443,242 |