Text 2789, 76 rader
Skriven 2008-04-03 04:20:32 av Scott Little (3:712/848)
   Kommentar till text 2742 av mark lewis (1:3634/12.0)
Ärende: Nomination
==================
 [ On 2008-04-01 at 22:11:24, mark lewis wrote to Scott Little ]

 ml> sya what? the FLAGS are in the LAST FIELD of the nodelist entry...
 ml> that they are broken into separate field is beside the point as far as
 ml> the nodelist and nodelist processing software is concerned ;)

What software treats the flags as a single field?

Even if it does, so what?

 SL>> Your method is just a lazy hack that pushes the burden of making
 SL>> his obsolete software work onto everyone else,
 ml> and what's so different about that then what was proposed years back
 ml> to do the =exact same thing= to those on the other side of the coin??

Which was?

 SL>> 1) dual-capable systems still need to list their IP info
 SL>> somewhere, so at the very least your method is redundant.
 ml> hunh? not if everyone still followed /traditional/ methods of listing
 ml> the contact information... this argument is 10+ years old :?

What?  The PSTN number can *only* go in one field, so if you have one of those
(and a great many do) you still need *another* field for the IP information as
well.  Ergo, your method is redundant.

 SL>> 2) mailers using your method are either incapable of contacting
 SL>> dual-capable systems via IP, or need the ability to pull the IP
 SL>> info from some alternate field anyway.
 ml> in a POTS/INET situation, do you think that POTS would ever be
 ml> preferential over (cheaper?) internet connections??

IP, obviously.  But your fake IP mailer only knows about the PSTN number, so it
can't make an IP connection to a dual-capable system.  Ergo, your method is
broken.

Or are you proposing that dual-capable systems move their PSTN number somewhere
else and put their IP/domain in field6 so your mailer works properly?

 ml> ummhummm... and where was this argument years ago when the majority
 ml> already had this capability that was stolen from them without their
 ml> knowledge?? and then, today, it is forced on them as the minority :?

Huh?  How was what stolen?

 ml> suggest that you refine your definition of "contact info" or "contact
 ml> number"... matter of fact, you should loosen your definition of it in
 ml> the same way that others have loosened their definition of "system
 ml> name" ;)

Apples and oranges (not that it matters much anymore, since INA has taken
over).  The system name field has always been a human not machine readable
field, so it breaks nothing and inconveniences no-one.  Using field6 for IP
forces all sysops to choose between IP or PSTN (because both is impossible) and
for both new and old software to guess whether the number there is an IP or
PSTN number; it might even contain protocol information (that's *definitely*
supposed to go in the flags field) or other such stupidity encoded into the
number.

Maybe you should loosen your definition of "flags field" instead.  Again, it's
more compatible and more flexible.  Your way, someone has to lose
functionality, even you.  The flags way, everyone gains functionality, even
you.

 ml> ummmhummm... and today, the majority of nodes are IP based...

Actually, they aren't.  And so what?  Even if a newer method is more common,
that doesn't give you the right to go mess with PSTN systems.  IP did not and
does not replace PSTN, it's a parallel method and needs its own place in the
nodelist.  Two methods cannot share the one field.


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

--- GoldED+/W32-MINGW 1.1.5-b20070503
 * Origin: You're an inspiration for birth control. (3:712/848)