Text 4003, 146 rader
Skriven 2012-09-15 23:05:18 av mark lewis (1:3634/12.0)
   Kommentar till text 3972 av Roy Witt (1:387/22)
Ärende: Pvt nodes vs points
===========================
 RW>> Frankly, it shouldn't present a problem. IBN denotes that the
 RW>> system does BINKD, and in this case uses port 24555 instead of the
 RW>> normal port.

 ml> INA comes before that which it serves...

 RW> Not according to the notes at the bottom of the nodelist. IBN is
 RW> listed first among those flags. INA is listed last...

it is not the positioning in the documentation that denotes the precedence...
it is the documentation of the flag, itself, that tells the story...

 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. 

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

 RW> Without referring to some remote document nobody other than a FTSC 
 RW> member can name, one should be able to rely on the info provided 
 RW> here.

that documentation, in Z1 at least, comes directly from FTS-5000 and/or
FTS-5001...

;S   INA - Place to list a Fully Qualified Domain Name Or Static IP
;S         Address, ***to be followed by applicable protocol flags
;S         offered.***   Usage:  INA:<somedomain.com>|<x.x.x.x>

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

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

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

 ml> it states this in the usage... in the example given, properly written
 ml> software will do a f.n.z conversion

 RW> Fuck that f.n.z shit. Its not needed.

 ml> of the address and then contact that way... the INA flag will be
 ml> ignored...

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

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

i'll stop there so as to not get repetetive -=B-)

[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?

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

 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.

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

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

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

 ml> agreed but /after/ INA so that IBN will use the INA specified
 ml> domain...

 RW> That's not per the description called for in the nodelist notes. 

read it again, please...

 ml> and IBN should also contain its :port portion since that IBN is not
 ml> on the default port...

 RW> Not according to the notes with ITN...the port should be listed
 RW> with the IBN address...

read it again, please...

 ml>> it may actually not matter, though, if there is a f.n.z DNS record
 ml>> for that node that points to the proper IP address ;)

 RW>> Jesssusss! Here we go with that f.n.z. crap again. Fuck that shit,
 RW>> don't bring it up again in my presence.

 ml> THEN DO NOT USE BINKD AT ALL! PERIOD! not even in DB!

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

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

 ml>  f.n.z is built into binkd and there is NO getting around it...

 RW> Wanna bet? Read what Nick says about that usage. It will be ignored
 RW> and not used in v3.83 of DB...

unless nick rewrites the binkd included with DB, this is a total falsehood...
and if he did actually do such, it would be an extremely stripped binkd that
would also not follow the published binkd/binkp specifications... it would be
quite incompatible in numerous ways...

 ml> your damned software and DO NOT bitch at ME when i point out how it
 ml> REALLY fuckin' works and i open your eyes to what is REALLY going on!

 RW> I'll believe what the author of that program says, not anyone
 RW> else's. Whether yours is the proper iteration or not.

the author(s) of that program, binkd to be spcific, are in the BINKD support
echo...

)\/(ark

 * Origin:  (1:3634/12)