ml>  MvanL> satisfied the requirement of whomever invented it.

 ml> i never said that dorinfox.def should carry more 
 ml> details... i said that it doesn't carry the node number 
 ml> internally... you extrapolated that on to something else...

The number in the dorinfo1.def dropfile file name was never meant to
designate a node number -- not dorinfox.def, not dorinfo#.def, not
"dorinfo dropfile" -- DORINFO1(ONE).DEF dropfile.

Do you understand the distinction between "The" dorinfo1.def
dropfile and "those" dorinfo(x|#).def dropfiles ?

 ml>  MvanL> If people deviate from the specification and adopt different
 ml>  MvanL> methods for using dorinfo1.def that's their perogative, which
 ml>  MvanL> doesn't change the fact that the number in the dorinfo1.def
 ml>  MvanL> dropfile was never meant to designate a node number.

 ml> you've still not provided the proof of this... i'm more 
 ml> than willing to look at it once it is made available... 
 ml> i would hope that it is written by the original author 
 ml> of the dorinfox.def specification ;)

http://en.wikipedia.org/wiki/Dropfile:

  DORINFO1.DEF
  RBBS-PC used this format exclusively. This file is 13 lines long.
  The name of the dropfile never changed, even if it was used in 
  multi-node environments.

Ie. "The name of the dropfile (dorinfo1.def) _never_ changed, /even/
if it was used in multi-node environments.".

Additionally,  

  DORINFO#.DEF
  Used by RemoteAccess, this allowed slightly more flexibility for one 
  to nine nodes. This is the exact same format as DORINFO1.DEF

Which is totally conclusive evidence that the RA mob initiated a
dorinfo(x|#).def propaganda against dorinfo1.def which the BBS community
later acquiesced towards.

You therefore are a victim of misinformation.


--- Maximus/2 3.01