Re: Other transfer codings

If length+data is the way to go then that should be the only way.. IE
either one overall content-length (in header) or a L+D mechanism.

Having a transfer-coding header invites alternatives/ something else
to negociate. It would be possible to mandate that all 1.1 -> 1.1 transfers
use the L+H format whether it be chunked or record. 

I noticed that people have already tried to suggest uses of lengths such as
00 000 and 000 for special meanings. If this is needed the record
proposal allows it via the padding??

Other people have talked about multiplexing etc. TCP/TCP?
Personally I don't advocate multiplexing.. I have done enough X25 / TCP/IP
and other systems already. Being able to send several requests at a time
and let the UA specify order preferences is good. (EG Must have A then give
me B,C and D with the smallest first)

> 
> However, it isn't sufficient for some encoding mechanism to simply be
> "workable". Lots of stuff is "workable", but we're not considering it. Given
> the high cost of supporting lots of encoding options each new one absolutely
> must bring some appreciable benefit to the party. The new MIME drafts make this
> a requirement for any new content-transfer-encoding, and I would suggest making
> it a requirement for comparable encoding facilities in HTTP as well.

Unfortunatly HTTP is heading in the direction of MIME (:-<

Early MIME had a chance. Like current http/gopher/ftp implementations there
are now just too many broken systems. The standard has become too large.

Pete.
-- 
The TIS Network Security Products Group has moved!
voice: 301-527-9500 x123 fax: 301-527-0482
2277 Research Boulevard, 5th Floor, Rockville, MD 20850

Received on Tuesday, 20 February 1996 10:46:59 UTC