Date: Mon, 3 Jun 1991 21:08:07 -0700 (PDT)
From: Mark Crispin <MRC(_at_)CAC(_dot_)Washington(_dot_)EDU>
Subject: re: comments on may draft
<<stuff deleted -- Neil>>
I believe that Content-Size should be retired. What we have now is a
wretched compromise which really isn't much good for anybody. Don't give me
the "efficiency" argument; "efficiency" is the enemy of reliability. What may
be "efficient" inside SUN is an UTTER DISASTER in the outside world. I don't
want to pick on SUN specifically since most other vendors of equally guilty of
inflicting their internal "efficiencies" upon customers who must then go to
great lengths to undo them.
The only valid reason I see for keeping Content-Size around is as a
validity check of the pre-encoded data. For this reason, if Content-Size is
kept around I propose retiring "LINES" and "ENCODED". As I have repeatedly
pointed out in past "what is a line?" messages, there is no reversible
transform between Internet lines and Unix lines. I also propose retiring BITS
as it is of marginal utility and in its place adding a new field which does
what is actually needed: the number of bits per byte.
Therefore:
csize := "Content-Size" ":" 1*DIGIT [ "/" 1*DIGIT]
The first number is the number of bytes in the original text and the second
digit is the number of bits per byte, the default being 8.
I can also deal with Content-Size being retired entirely.
The function that Neil proposes for Content-Size should be permanently
relegated to an X-mumble field, to emphasize expressly that it is NOT
supported outside of a well-controlled playground.
We can NOT be mealy-mouthed here. I understand perfectly well what SUN
and PRIME want, and I sympathize completely. But!! they MUST accept that it
can NOT work reliably in the general catanet, where body munging is a sad fact
of life. BY ALL MEANS, they should not feel as if we are constraining them
from using it internally. There is a perfectly good mechanism, the X-mumble
header lines, for doing this. We simply can not bless it for the outside
world, and we should encourage these vendors in the STRONGEST POSSIBLE TERMS
to NOT use it in customer released software.
-- Mark --
I actually don't think that there is all that much disagreement
between us. I'ld like to describe (again) what we intend to do
with the field. Then people can decide whether this function has
a place in RFC-XXXX or not, and if so where it should go.
First an observation: at least in our domain, RFC822 is used for
more than just transmitting messages. It also is the "glue" used
to communcate between "message stores" and user agents (to use
the X.400 terminology), where message store is typically either
a directory full of files with one message per file, or many
messages per file concatenated together.
We want these sizes in order to standardize some communication
between the message store and the UA, *NOT* between the sending
UA and the receiving UA. While we could add these things as X-Sun-length
fields, we thought that this would be a very common thing to want
to do, and therefore should appear in the standard. We expect to
generate these fields upon receipt; we would even be willing to
insist that a sending UA needs to strip these fields off of a
message to ensure that they couldn't cause problems upon receipt.
So, should RFC-XXXX have any provisions that are intended to help
message stores? Is this a place in the protocol hierarchy that
is OK to solve?
Does this make anyone happier :-> ?
Neil Katin