re: comments on may draft

[Neil.Katin@xxxxxxxxxxx (Neil Katin)]

> Date: Mon, 3 Jun 1991 21:08:07 -0700 (PDT)
> From: Mark Crispin <MRC@CAC.Washington.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