Re: nsb@thumper.bellcore.com (Nathaniel Borenstein)'s mail

[Hitoshi Doi <doi@xxxxxxxxxxxxxxxxxx>]

# Excerpts from mail: 25-Feb-91 Re: RFC 934 for multipart .. Erik

	[..stuff deleted here and there..]

# In the same spirit, I should say that I certainly agree that the issues
# are separable.  That is, one could pursue the kind of solution I'm
# advocating quickly in the current 7-bit SMTP world, and simultaneously
# pursue a strategy of upgrading SMTP to permit 8 bit data.  I see no
# fundamental conflict here, though I do believe that upgrading SMTP will
# be a much slower process.  Basically, I only argue against 8 bit SMTP

	I see many people stating that converting to an 8 bit SMTP
	will be a slow process.  Correct me if I'm wrong, but
	I think that people who want an 8 bit SMTP will convert as
	soon as possible.  I would like to hope that major gateways
	would convert quickly too.  But the rest of the people don't
	need to change as they will probably never see or need 8 bit
	text mail.

# because I'm not convinced it is worth the effort, not because I think it
# is intrinsically wrong.  I'd certainly be happy to separate the
# arguments, and to give some consideration to how a 7 bit 1049/934
# solution could be designed to gracefully upgrade to use 8 bit SMTP when
# it becomes available.  (I.e. we should design it so that there is a
# standard 7 bit encoding for 8 bit data, but also a standard method of
# interpreting 8 bit data if and when the mailers begin to pass it
# through.  This might imply something like the use of a Content-Encoding
# header to accompany the Content-type.)
# 
# This strikes me as the beginning of a good compromise that might lead to
# a consensus.  Other opinions?

	How about no conversion at all?
	Just let the 7 bit SMTP clients strip the mail.
	In most cases, the sender and recepient of 8 bit text mail
	are pretty close to each other.
	Shouldn't the interpretation of the 8 bit text be left to
	the sender and recipient?

Hitoshi Doi, International Systems Engineering    doi@jrdmax.jrd.dec.com
Japan Research and Development Center             decwrl!jrdmax.enet!doi
Digital Equipment Corporation Japan               doi@decvax.dec.com