Re: Other transfer codings

> 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.

Agreed. SMTP dot-stuffing can be made to work, as the enormous installed based
of SMTP clients and servers that use it successfully on a daily basis
illustrates. It can even be made to work in the case of binary data, although
things tend to get a bit ugly  -- e.g. what constitutes a line break where
stuffing may be needed? The binary SMTP extension elected to use a chunking
mechanism rather than dealing with all this stuff, and I think it was the right
way to go.

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.

The only conceivable benefit SMTP dot-stuffing could bring is some sort of
strange compatibility with SMTP itself, but this is silly because the material
underneath the dot-stuffing isn't necessarily compatible with SMTP (line
terminators, use of binary MIME, etc.) and has to be scanned and often as not
converted anyway. Besides, dot-stuffing is often done on-the-fly and cannot be
counted on to exist outside of the on-wire data. It's not like reusing the
three lines of code it takes to implement dot-stuffing in your typical SMTP
application is worth the bother!

The same sort of argument applies to the proposal to add APOP capabilities to
HTTP. Security mechanisms are also quite costly to deploy, and given that the
digest authentication mechanism already provides comparable shared-secret
mechanisms I see no reason to add APOP specifically. In fact I would have
liked to pull APOP out of POP3 completely and instead integrate it into
the more general AUTH security framework described in RFC1734. The only reason
this wasn't considered was the installed based of existing APOP usage.

Now, if somebody wants to argue that either dot-stuffing or APOP provide
material advantages if implemented in HTTP, I'm all ears. But nothing presented
thus far has made this case for me.

				Ned

Received on Tuesday, 20 February 1996 13:25:43 UTC