Hello mark!   
      
   15 Feb 06 04:57, mark lewis wrote to Matt Bedynek:   
      
    ml> speaking as one of those folk, /i/ don't forget... i _know_ that there   
    ml> is software available for those who can't/don't want to handle large   
    ml> messages... this software can cut/split (by FTSC proposal) messages   
    ml> too large for their systems to handle... i've said this for years...   
    ml> in fact, i've had this stance ever since the ^aSPLIT proposal was   
    ml> presented to the FTSC... i have /always/ believed it the   
    ml> responsibility of the -=recieving=- system to split messages according   
    ml> to _their_ capabilities rather than "forcing" everyone else to succumb   
    ml> to their individual restrictions...   
      
   This is really a dirt-common networking design issue that has been addressed   
   in both hardware and software protocols years before Fido emerged.  There are   
   appropriate data structures and algorithms to accommodate datagrams of fixed   
   length or variable length, but unfortunately Fido standards failed to define   
   quite enough technical detail to realistically accomplish either.   
      
   Nobody in Fido has hardware and software that can process and forward   
   infinitely sized messages, though that is what is effectively allowed by the   
   Fido standards.  The advantage of a formal splitting algorithm is that it   
   implies a formal unsplitting mechanism, which means that all are not required   
   to "succumb" to the lowest common denominator determined by one worst-case hop   
   on the route.   
      
    MB>> I suspect there are tossers that stop up completely when they   
    MB>> encouter very large messages?   
      
    ml> i don't doubt that... that's one of the main reasons why i see that   
    ml> ^aSPLIT proposal is written and directed to the wrong folk...   
      
   All Fido systems are theoretically "tranceivers", so it is really irrelevant   
   whether the responsibility for the execution of the algorithm is assigned to   
   the sending process, the receiving process, or distributed between   
   both...since we'd all need to support "it", whatever "it" is.  Whether I like   
   messages "too small" or you like messages "too big" is simply a matter of   
   perspective...and there is a technical path to render it transparent to us   
   both.  Unfortunately, the necessary groundwork to lay the infrastructure to   
   resolve the issue came along a little too late to benefit the folks that need   
   it the most.   
      
   .\\ike   
      
   --- GoldED 2.50+   
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)