>> the specs for packed messages stating that the message body is
>> > unbounded

 WG> I'm with you on that one. Things like max # of nodes are
 WG> fixed at a single byte in the "spec", which means that
 WG> increasing it breaks everything.

yup... in that particular case, i agree...

 WG> Increasing the message size limit, OTOH, only breaks broken
 WG> software. That doesn't bother me as much.

hehehe... i hear that >

 WG> And, IIRC, it said that in plain english in FSC-0001. And
 WG> that's how I implemented it on my Commodore 64 when I wrote a
 WG> tosser years back. So, I could it do with < 64K RAM
 WG> available, surely anyone else can do it in 640K. :)

the only thing i see is that one must be able to code a buffering system so
that they can get to all the control data they need and still be able to
process the message... buffering to disk may be slow but it works... the
control data i am thinking about is the stuff at the end of the messages...
for systems that toss to the message base at the same time they pack for
other systems, getting to the seenby and path lines before starting the
actual toss is needed... unless i'm missing something >

)\/(ark