[Fwd: long fragment implementation.]

From: Justin Chapweske (justin@cyrus.net)
Date: Tue, Oct 12 1999

Message-ID: <3803DE57.EACBB11D@cyrus.net>
Date: Wed, 13 Oct 1999 01:20:23 +0000
From: Justin Chapweske <justin@cyrus.net>
To: ietf-http-ng@w3.org
Subject: [Fwd: long fragment implementation.]

By Mike's suggestion I am forwarding this question to the mailing list.

attached mail follows:

Message-ID: <3802551E.6A7D5D13@cyrus.net>
Date: Mon, 11 Oct 1999 21:22:38 +0000
From: Justin Chapweske <justin@cyrus.net>
To: Mike Spreitzer <spreitze@parc.xerox.com>
Subject: long fragment implementation.

Looking at your implementation in ILU shows that if the fragment size is
larger than what the regular 18 bits can hold, then you set the
long_fragment bit and ONLY use the additional 32 bits for the fragment
size, leaving the 18 original bits completely empty, is this implementation
correct?  Because if so, I think that I might have some ways to, in an
easily implementable and consitant manner, more efficiently use those 18
bits, while at the same time supplying more than 8 bits for session id's
and atom ids (256 / 2 session ids for one direction is simply waay too

If this implementation is correct in regards to the SMUX spec, then I will
do the same for my implementation.  Then after mine is completely
implemented and interopable with your implementation, I will propose some
changes to the protocol that might be beneficial.


-Justin Chapweske, Cyrus Intersoft