Re: the 8-bit dilemma

Brad Knowles (brad@azathoth.ops.aol.com)
Wed, 28 Feb 1996 20:32:55 -0500 

On Feb 28,  2:21pm, Michael Elkins wrote:

> IMAP is a problem for what you want to do with it.  However, you won't be
> able to control what people _send_ to you, so having an optional parameter
> will not help.  I can guarantee that you will receive mail with the
> Content-Type hidden.

    I agree that you will get some messages with the content-type
hidden, but I also agree that providing the option of unhiding the
content-type is important.  Now, as to how the user agent or the
secure email standard is implemented so as to accomodate that, hasn't
yet been discussed.

    We already know that IMAP will have to be modified and will have
cases where it has restricted information about the opaque object.
But for those cases where it isn't a leak of information that should
be kept secure, to be "IMAP-friendly", I think we want to be able to
provide the option.



    This kind of gets down to my philosophy that I mentioned to Dave
after the workshop on the way to dinner.  To wit, when designing a
standard, it is important to avoid being gateway-hostile where
possible, and where feasible, it is important to be gateway-friendly.
However, when it comes down to the final analysis, you can't let the
issue of gateways get in the way of designing (and implementing) good
standards.

    Dave himself said that, at their very best, gateways are designed
to lose a minimum of information, and towards that end they will never
be 100% native.  You can't cripple the native implementations simply
because the non-native implementations can't understand or deal with
something.



    This is a case where I think of IMAP as a "gateway" of sorts, and
we know that the current IMAP standard will not be capable of dealing
with the standards as recommended in RFC 1847, so the "gateway"
standard needs to be modified.

    However, since I think we have the possibility of being
"gateway-friendly" in the case of allowing optional unhiding of
nominally opaque content-type information, I think we should step
forward and put that into our proposed standard.  This doesn't
necessarily mean that it will get wide use, but I don't see it doing
any particular harm from our perspective and I can see it potentially
doing a great deal of good from the IMAP perspective.


    Now, if I'm wrong, then I'll be glad to retract this position.
But you're going to have to convince me that I'm wrong.

-- 
Brad Knowles                           MIME/PGP: BKnowles@aol.net
    Mail Systems Administrator          <http:www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148