ietf-822
[Top] [All Lists]

Re: C-T-E's (was Re: NULL)

1994-10-24 16:49:25

My point is, and has always been, that I would like to see C-T-E's of 7bit,
8bit, and binary removed from the MIME spec.  
 
How would you propose to indicate whether a body part can be carried, without
further encoding, over (a) traditional internet mail transport, and (b)
traditional internet mail transport modified to not strip the 0x80 bit?

--

Using 7bit/8bit/binary as c-t-e may seem like a bit of a wart, but it *is*
important to carry this information in the message, and it must be carried
separately from the content-type.  

While it would be conceptually cleaner to have separate values for "encoding" 
and
"requirement for mail transport", doing so would also introduce meaningless
states (like base64 encoding + binary transport).

To justify such a fundamental change in MIME at this point, would require that 
we
find a serious error in the MIME spec as written that prevented 
interoperability.
To this date, I've seen some instances where the MIME spec was apparently
mis-read, but these would seem to indicate a clarification to the spec rather
than such a major change as you propose.

A well-documented design flaw is still a design flaw.

But this is not a well-documented design flaw.  It's a reasonable design
that is less than adqeuately documented.

The fact remains 
that there is software that uses "C-T-E: binary" in a manner it is not 
supposed to.

This does not amount to a proof that the spec is flawed.  There are many
other possible explanations for an incorrect implementation.

If there was a single C-T-E of "none" instead of the current 
three non-encodings, this would not have happened, and will not in the 
future. 

No, but other flaws could have cropped up as a result of your design.  Would you
have us repeat the proposed/draft standard cycle just to find the flaws in your
proposal instead of the ones we have now?

What's more, by proposing a seriously incompatible change to MIME, would you 
have
us scrap (in addition to the broken implementation you mention) all of the other
MIME software out there that interoperates reasonably well?

The benefit to be gained by the change you propose is questionable at best, 
while
the cost is demonstrably large.

Removing NULL from the list of valid chars. is also an incompatible change 
to RFC 822.  No?

Not really, because it won't break ANY of the installed base.  Essentially none
of the existing UAs or MTAs will pass NUL transparently, so software written to
an "RFC 822 without NULs" spec wouldn't be any less functional.

Keith Moore

<Prev in Thread] Current Thread [Next in Thread>