On Mon, 26 Aug 91 02:39:20 -0400, leo j mclaughlin iii wrote:
Though I'm not sure what you mean (depending on who's argument you're
following, nested encoding either makes UAs easier or harder at the
expense or benefit of MTAs), we did come to cloture. It was clear
that the working group was divided, it is hoped implementation experience
will allow a more decisive vote in New Mexico.
Those of us who are implementors have already said everything that needs to be
said on this issue. Interested parties are cordially invited to read the past
6 months' worth of e-mail on the subject before making any further commentary.
Enough discussion!
I insist upon a vote on the question NOW. **NOT** in New Mexico. I can not
wait until then. I must learn whether I should continue to bother with any of
the work of this WG, or if I should go off on my own and do something that
works for me and my users. If this WG can not conduct its business and make
decisions via e-mail then it has no business in deciding the future of e-mail.
The question before us, the general question that encapsulates all the "nested
encoding" questions, is:
==> SHALL ENCODINGS BE PERMITTED ON CONTENT TYPES MESSAGE AND MULTIPART? <==
My vote is: NO, NO, 1000 times NO!!
Furthermore, I suggest that suitable modifications be made to the RFC-XXXX
syntax so that the concept of encoding for content-types MESSAGE and MULTIPART
becomes non-existant. This probably would involve folding encoding into the
content-type syntax, with which Messrs. Freed and Borenstein may not be happy.
If so, that's OK; it's a suggestion, not a show-stopper issue. Encoding on
MESSAGE and MULTIPART is.
-- Mark --