Re: smtp charter (reviesd)

[katin@xxxxxxxxxxx (Neil Katin)]

> Subject: Re: smtp charter (reviesd) 
> To: Stef@ics.uci.edu
> 
> >I think you should very seriously consider defining a new protocol
> >that may very well carry RFC-XXXX body-parts (Yes, I agree to stop
> >using RFC822bis as requested).  It might also carry full binary.  It
> >might also carry ASN.1 objects!  Maybe call it SX.400 for "Simple X.400?
> 
> Stef,
>   I think this is a *wonderful* idea.  It could perhaps be done really 
> efficiently by adopting some appropriate profile and looking at ISODE or 
> the equivalent, at which point one could simplify further and call it 
> "X.400" with no need for clarification.

(lots of stuff deleted...)

John goes on to suggest that Stef is trying to kill a nice simple idea
by forcing extra features on it; that anyone who wants binary transport
and multiple body parts are better served by using X.400.

I think that John has touched on one of the basic assumptions that
people may disagree with -- should SMTP/822 be extended to support
the "usefull" (I know, that's a loaded term) functionality that is
present in X.400 and being demanded by near term customers, or
should we limit SMTP/822 and encourage people to switch over?

I think that one of the reasons why there was so little concrete
agreements in St. Louis was that people did not agree on the
assumptions (like where do we want to take SMTP).

I know that the reason that I stopped supporting the "wretched"
(sorry Greg) solution was that it appeared to be not simple
to implement, where simple is more in terms of an administrative
and compatibility model that would be presented to the user.
I suspect that it would take several years before the SMTP
community reaches critical mass with any new transport, and that
given the fixed cost of making any change to the transport
(not engineering, but support and maintainability costs) we
should make the change large enough to justify itself.

This is why I think that Stef is "right on the money" -- if we're
going to bother to change SMTP at all we should make sure that the
change is large enought to cover the considerable costs involved
in making any change, no matter how small.

We originally started with a significant list of possible SMTP
changes.  We narrowed the list down to "pass 8 bit chars to support
international character sets".  For better or worse, a plurality
of the working group insisted that this be done in a rigidly compatible
way (as opposed to just endorsing the current defacto changes that
have already been made to many SMTP agents).

As has already been pointed out, once you want to support rigid
backwards compatibility, your user agents already have to have
covered all the cases for passing 8 bit text within a 7 bit transport.
If we stay with rigid compatibilty and still want to change SMTP,
then I want to support more than just 8 bit text; I want to fix
my other big problem -- passing binary data.

Call it creaping featurism if you want, but I think of it as meeting
my customer's needs.

	Neil Katin