Text 4079, 163 rader
Skriven 2012-09-18 15:52:14 av mark lewis (1:3634/12.0)
     Kommentar till en text av Roy Witt (1:387/22)
Ärende: Pvt nodes vs points
===========================
 RW>> if they need to be in a certain order, then the description of
 RW>> where they go should be included or at least list them in order of
 RW>> appearance in a nodelisting.

 ml> it is but it cannot be shown in a simple listing of the flags in a
 ml> documentary method...

 RW> It better, otherwise there's nothing to back up your comments that
 RW> certain flags are out of order.

INA followed by no flags is invalid... this is plain to see in its
documentation at the end of the nodelist and the FTSC document from which it
was extracted... i quote again "to be followed by applicable protocol flags
offered"...

 RW> In which case, all flags are going to be listed as the node or 
 RW> their *C wishes them to appear.

developers have been trying to educate *Cs since the beginning of the
network... for the most part, a pretty good job has been done but there are
times, though...

[trim]

 ml> note: *** emphasis added... it specificalls state "to be followed" ;)

 RW> Yeup. But that doesn't appear to be the norm, as pointed out to you
 RW> with Z3 nodes putting their emphasis in the BBS field and adding a
 RW> PVT flag to the IP only nodes.

i did not specifically name any zone nor did i pick any one in particular out
for my comment... besides, Z3 isn't violating any published format specs...

 RW>> If that's incorrect, then it's no wonder people are using flags in
 RW>> a way that isn't called for.

 ml> they're not reading the documentation fully or they are not
 ml> understanding it :/

 RW> If it isn't correctly presented at the bottom of the nodelist,

who reads the nodelist?!? the fact is that extremely few people look thru the
nodelist... heck, there's not even anything used these days to pull the notes
from the nodelist and make them available separately so the sysop might notice
a change IF they even read that when it becomes monotonous...

 RW> which is used by every sysop in that list, then there's no reason
 RW> to bitch about it being used inappropriately when a remote document
 RW> isn't distributed to everyone on a weekly basis.

the FTSC documents have NEVER been distributed to all nodes on a weekly
basis... the FTSC library is the technical library for most all things FTN and
if someone has a question about something technically related, like the
nodelist and its flags, then they should endeavour to find themselves a copy of
the FTSC documentation that covers that... i'm not saying that *Cs should have
a copy of this library and make it available but i and several others have done
so... in my case, i was doing it long before i became a *C...

[trim]

 RW>> Somebody should inform the zone nodelist clerk of this. No wonder
 RW>> some of the software doesn't work as it should.

 ml> this has been done for several zones... this is one reason why
 ml> several zones are also going thru a rework of their Txy (online time)
 ml> flags which were erroneously stated as being "userflags" when they
 ml> never were and never intended to be... in this case, it was a
 ml> documentation error and, as such, numerous programs (eg: Z2C's
 ml> nodelist flag checking program) were written to enforce the flag
 ml> incorrectly... they are working, now, to fix these flags so they are
 ml> not behind the 'u' userflag indicator... if/when that nodelist flag
 ml> tool will be updated is another matter altogether ;)

 RW> Yeup...hidden in some obscure document that nobody reads.

even if it was shoved in their faces when they're taking their morning
sabbatical in the library, they'd not read it...

[trim]

 RW>> I like the idea of listing the internet address in the BBS field
 RW>> because that places it where it can easily be found by both human
 RW>> and robot and doesn't interfere with the use of a flag as intended.
 RW>> And the excuse given that a BBS no longer has a place to list
 RW>> itself, well?

 ml> yeah... this argument has been hashed thru many times before, too...
 ml> my system's name is "Waldo's Place USA" and there are many domains
 ml> for it... i cannot list them all in the field you suggest and i won't
 ml> because its name is not any portion of the FQDN's that it handles...
 ml> field 6 is the "contact number" and it is the ideal place to list the
 ml> IP number or FQDN *BUT* that field cannot handle multiple IPs or
 ml> FQDNs... so, we're right back where we started from and having the IP
 ml> or FQDNs specified after the individual I??? flags and optionally
 ml> followed by ":port" if those services are not provided for on the
 ml> default port...

 RW> Too bad no one realized this would present a problem back in 1985,
 RW> eh? 

it wasn't a problem in 1985... in 1995 it was starting to show if it hadn't
already... i know that when it was first proposed to put the FQDN in the system
name field that i very definitely voiced my negativity to that... i have
continued to do so every time it has come up, too... my system has a name and
it has a FQDN... they are no more the same things that your toilet seat is a
spare tire for your car... sure, you can sit on them when they are oriented a
certain way but they are not interchangable...

 RW>> Having to look at a bunch of flags for a internet address is
 RW>> stupid, when those flags can be used to list a port other than the
 RW>> default port for a protocol if it's called for.

 ml> but, even though the nodelist is human readable *if the human also
 ml> knows what the flags mean*, it is intended to be machine-readble...
 ml> we can count our lucky stars that the distributed nodelist is not
 ml> binary which would be even mode machine-readable and compatible ;)

 RW> more--------?????------------^

yeah...

 RW>>> IBN should still be in the listing though.

 ml> NOT for those systems that do not offer binkp connection
 ml> capabilities! witness all those systems that mistakenly list(ed in
 ml> the past and maybe even today) ITN (telnet) capabilities which they
 ml> do not offer via FTN mailer but only for user connections... IFTP and
 ml> IHTM protocols also fall into this area... if there is no mailer that
 ml> can answer and handle IFTP and/or IHTP connections, then they should
 ml> *NOT* be listed in the nodelist since the nodelist is for
 ml> **mailers**...

 RW> And humans.

i disagree... especially since the "St. Louis" format nodelist was developed...
previously it was human readable but not intended to be purely human readable
after that without the necessary knowledge of the flags and what each field's
contents were...

[trim]

 RW>> I'd rather not have to get into that shit.

 ml> sorry... i know and fully understand... but the facts still remain...
 ml> f.n.z is a default part of today's fidonet over internet
 ml> capabilities... it does, actually, extend and enhance our network's
 ml> capabilities for connections...

 RW> If one can understand that shit. Going to a Russian site to read
 RW> the particulars leaves a lot of unanswered questions in my mind.

i don't doubt that... it does the same for many...

 RW> Reading about CNAME vs DNAME vs ETC. at Wiki also leaves a lot to
 RW> be desired. 

that cannot be helped much, either... those items are defined in internet
standards (aka RFCs)... if you have problems with FTSC specs, you'll definitely
have a problem with RFCs...

)\/(ark

 * Origin:  (1:3634/12)