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+