Re: Other transfer codings

> Hi I would like to see other transfer codings in the 1.1 spec. The following
> is a rough of the sort of thing that could be used.

Why?  What is their justification?  The fact that they are discarded relics
from other network protocols is not a justification.

> ------------------------------------------------------------------------
> Existing protocols on the net have a number of ways to
> provide end of content markers in a data stream. This document proposes
> the dot stuffing mechanism that is used in protocols such as RFC1725, 
> RFC 821 and others. It also proposes another Record coding mechanism as
> used in the SSL draft.
> 
> Transfer-coding: dot-stuffed
> 
> This coding is most applicable to text orientated streams. The end of content
> marker is the character sequence
> 	<CR><LF>.<CR><LF>

That would be insane.  Why on earth would we want to introduce a
content-destructive length marker when we already know it was a
total failure in SMTP and caused endless amounts of grief until 
applications finally dumped it entirely in favor of fixed lengths
and MIME?

> Transfer-coding: record
> 
> The record coding uses the same format as used in the SSL draft standard. This
> considers the content as a set of records. Each record has a two or three byte
> header that says how many data octets are in the record body. The three byte
> version allows some padding to be specified. The EndOfContent marker is a 
> three byte sequence that indicates 0 bytes of data and 0 bytes of padding. So
> two byte headers specifying 0 bytes of data can be used without implying EOC.

This is just a limited and less efficient version of chunked encoding.
And, BTW, SSL is not a draft standard.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 20 February 1996 08:28:59 UTC