Re: Setting the stage

On Jan 30, 2004, at 9:33 AM, Paul Smith wrote:
> > and "kill the dot". If you've done any kind of serious email hacking, 
> > that phrase should make you twitch. And fundamentally, you can't take 
> > SMTP out of the 7bit, 1200 baud modem era and still realistically 
> > call it SMTP, or make it reasonably backwards compatible with SMTP.
> Actually, those are two reasons that I think are NOT good enough to 
> warrant discarding SMTP..
> Neither of those reasons will bother your average user in the 
> slightest!
agreed. but they aren't intended to be. And to a good degree, I believe 
that the migration from SMTP to mail-ng isnt' an end-user thing anyway, 
but an admin thing, and that for the average user, should be primarily 
invisible, or at worst, trivial. We shouldn't *have* to convince 
average users to support this upgrade, any more than an average user 
should be involved in deciding whether or not to upgrade to IPV6.
> No, you didn't read far enough. Having mandatory SMTP extensions - eg 
> 8 bit data would be fine IF it was called a different protocol and 
> didn't have to maintain backwards compatibility with SMTP - eg on a 
> different port with gateways to communicate with SMTP servers.
Okay, I see the point. Not sure I agree with it, I see it.

>  We'll need gateways anyway for whatever new protocol is designed (if 
> any), so why throw away the good with the bad.
Agreed.

> > chance to take what we've learned, apply modern design methods to it, 
> > and move on to something that doesn't require a PhD to send a bloody 
> > message...
> Actually, that's not the problem.. It's really incredibly simple to 
> send a message using SMTP..
Trivial ones, yes. I spent 7 hours yesterday looking for the magic 
incantation needed to convince a piece of perl code to send an e-mail 
in Chinese and Korean without greeking the text. When you take SMTP, 
layer on the 15 or 20 RFCs we've layered on top to wedge all of the 
things we've wedged onto it in the last 15 years, and then try to use 
all of that stuff to do what you need to do, and then watch as email 
clients all over the network fry their little algorithms and get RFC 
compliant e-mail wrong...
it's not simple any more. Except in trivial cases.

(for the record, the reason it was greeking was a data store problem -- 
it turns out pieces of the text weren't in UTF8 as they were supposed 
to be, and when you take big5 and send it out as UTF8, bad things 
happen... )
> That's why you make 'SMTPV2' incompatible with SMTP, but built on the 
> same building blocks to aid migration.
I agree with the first part. The second part I have issues with, 
because it lends itself to never pushing the legacy stuff out the door 
and into retirement. If they're completely separate and gatewayed to 
each other, you can create reasons to 'encourage' folks to make the 
migration. If you merge them together, you're going to support both 
code bases for the rest of reality, until mail-search-for-spock comes 
along and reinvents all of this a third time.