Re: Setting the stage

On Feb 1, 2004, at 1:30 PM, Paul Smith wrote:
>

> But, (to play devil's advocate), let's assume that we take SMTP. Make 
> all 'user readable' headers (subject etc) into UTF8, make message 
> content UTF8, make it support binary transport, etc, and make it so 
> you KNOW that whatever mail server you talk to, it MUST support that 
> stuff.
>
> Now, would it be as hard to send that Korean text? Could you make it 
> much simpler?

I'd argue yes.

One way it'd be simpler is that we could depend on clients at least 
doing the rational thing. I spend a lot of time working around client 
issues. I'm not even talking about issues where they haven't 
implemented an RFC -- I'm talking about them implementing them 
blatantly wrong.

But ignoring that aspect -- yes, it'd simplify life for generators and 
reader software alike. We could unwind some of the complexities we've 
created by taking email, then inventing MIME, then layering MIEM with 
this, and MIME with taht, and then layering those extensions with this 
extension, and... how many RFCs are there that define various things 
about MIME now, anyway? 15?

So simply by taking all of that back to square one, and re-implementing 
it in a way that takes all of those needs and requirements into 
consideration, you simplify life for e-mail massively.

> This is what I was saying MAY be an alternative to totally redesigning 
> everything and throwing away all that has been learnt from SMTP.. I'm 
> not saying that's the way it should go, just that this possibility 
> shouldn't be ignored. It's not some more SMTP extensions, it's a new 
> standard which is based on SMTP but with problems fixed.

we're probably in violent agreement here, actually, because email-ng 
probably looks a lot like SMTP. but I argue strongly that they have to 
be separate, not layered, and gatewayed, not interoperable.

Why? because otherwise, we'll never make that old mess go away. Legacy 
code is a bastard, and you need to make the transition clear, or you 
end up supporting BOTH code bases forever, and that's not a solution 
here, that's just even more chaos. Even if it takes ten years to make 
that transition, or whatever, that's better than realizing your saddled 
with both systems forever...

>> 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.
>
> But why throw away mature, bug fixed code and bring in new, buggy code?

mature, buggy code? (grin)

Same argument can be made in the physical world: why do we sometimes 
choose to tear down a building and build from scratch instead of adding 
on to an existing building or repairing it?

1) because the existing building can't be saved, it's beyond repair

2) because the existing building doesn't serve the new needs and can't 
be retrofitted in a cost-effective way

3) because it's cheaper to start over than patch up what you have

aspects of all three relate back to this discussion. The "mature, bug 
fixed code" started out as a one-story bungalow, and now forty remodels 
later, is a five story office building with 12 bathrooms and a hotel on 
the top floor. And the building inspectors have warned us it has 
termites and isn't earthquake safe, and it'll take more money than we 
have to retrofit it -- and even if we do, it'll look like hell, because 
each retrofit had a different architect so none of the updates match 
styles...