Re: Other transfer codings

"Roy T. Fielding" <fielding@avron.ICS.UCI.EDU> writes:
> > 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?

The dot transparency protocol is an essential part of SMTP, as defined 
in RFC821, it has not been 'dumped' and headers, MIME or otherwise, do 
not replace it. On the contrary, RFC1123 emphasises this point very 
explicitly in section 5.2.11 "Implementors MUST be sure that their mail 
systems always add and delete periods to ensure message transparency." 
The emphasis is probably because getting it right is a configurable 
option if you use sendmail.

The main disadvantage of this approach is that the data stream has to 
be processed serially to insert and remove the dots. The additional 
server load scanning and inserting dots would be the limiting factor 
here. Someone is sure to implement a broken version in the name of 
efficiency if this sort of mechanism is adopted in this context.

The fewer transfer coding mechanisms the better as far as I am 
concerned. As far as I can tell, chunked does what is needed, so adding 
other options will just make it easier to fail to communicate due to 
feature mismatch.

Owen Rees <>
 All my news postings and e-mail are personal opinions.
 Information about ANSA is at <URL:>.

Received on Tuesday, 20 February 1996 09:53:07 UTC