ietf-smtp
[Top] [All Lists]

Re: I-D ACTION:draft-klensin-email-envelope-00.txt

2004-01-24 06:31:47



--On Friday, 23 January, 2004 22:24 -0500 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

...
So for instance, the previous paragraph is why *any* proposal
that doesn't provide benefit until 98% or so of the net has
deployed it is doomed to fail unless you give a *really* good
explanation of why 98% of the people should deploy it when it
isn't going to give them any benefit if 3% of the OTHER people
don't bother....

Valis,

I want to comment on the above, since I am in the process of proposing some things (the subject draft is only part of the package) that, from a deployment standpoint, give me the shakes -- and that should give anyone who has dealt with those issues, as you obviously have, similar anxieties.

At the antispam conference at MIT a week ago, there were an astonishing (to me) number of proposals that seemed to be based on the premise of "as soon as everyone on the network adopts this technology, everything will be wonderful". And, as you suggest, the reaction among all of us with significant deployment experience was either "yes, right. next?" or "when pigs fly". It isn't even worth the effort to stand up and ask those folks pointed questions any more. If you ever see a proposal with my name on it that proposes to cure spam (or the common cold) but requires Internet-wide deployment to be effective, you can safely assume that either the sender is an imposter or that I'm coming off a several-day drunk spell.

"If we managed to get this widely deployed ... it would help with ... or provide a framework for ..." is not that type of statement or proposal. It is just an observation. In that context, the _purpose_ of this proposal is to explore whether it is possible to remove (or start removing) a fairly serious wart in the way SMTP works without junking the infrastructure. Would it be worth deploying if that were the only result? Almost certainly not (at Nathaniel corrected pointed out). Might it be worth deploying if it were part of a bundle of things that addressed an important problem (or group of problems) and cleaned some other things up? Maybe, and that is one of the questions in front of us.

And, for precisely the reasons you identify, I want to explore what we really need from "mail NG" and what it would look like in the context of SMTP on Port 25. Perhaps we could do better if we started with a clean slate. But the costs --and risk of complete failure-- if we create a new mail infrastructure on a new port and try to transition to it are so formidable (even trying to work out the implications of DNS MX records boggles my mind) and frightening that it would be really attractive to avoid them.

But, it is equally important to note that there are some of these things that can be slipped in without requiring Internet-wide deployment to work and we should try to leverage them when we can. We have looked at "Internet Fax", come to the conclusion that some of the needs of that community are a bit strange relative to the basic email infrastructure but that they _are_ a community, and gone ahead and specified things that make enough sense to them that they will deploy (and are deploying). At least some of those extensions will eventually appear in mainstream SMTP MTAs, but many of us probably won't notice them when they do... and won't miss them until then. One could make similar arguments for SMTP extensions that make sense within an enterprise, or otherwise between consenting adults, but maybe not on the public Internet (this is, after all, why we have X-commands).

Interestingly, one of the ways of looking at internationalization at the header and envelope level is that it is more like fax than it is like "needs to be deployed across the whole Internet to make things work". Remembering that the content part of the problem (can I send you something in a language that you don't read, have it arrive intact, and expect you to go out and find a translator) seems to have been solved a decade ago with the introduction of "content-type: text/plain; charset=...", and the potential for language tagging at the body part level, many years ago. I've been surprised at how little I've seen multipart/alternative used with texts in different languages, but that seems to reinforce my present hypothesis.

The hypothesis is that the serious, crying, demand for i18n email addressing, and UTF-8 headers, etc., is communications within groups that share a language and script (primarily where one or the other isn't English/Roman-based). Anything that is specified to enable those groups to communicate naturally intra-group had better still interoperate plausibly with the rest of the Internet, and with each other, or we kill email as a universal, worldwide, tool. But, just as we (implicitly) told those who where anxious to have multimedia facilities that they weren't going to get them in a convenient and interoperable environment until they --and their multimedia correspondents -- upgraded to MIME, I think it is plausible to say to the community that most wants i18n addressing,

        "This is a big change, as you know better than anyone
        else.  Nothing we do technologically is going to solve
        the problem of a user of Chinese communicating with a
        user of Hindi without understanding each other's
        languages or reading each other's scripts --especially
        for addressing, where the character strings in addresses
        may not be in either dictionary -- and, hence, you are
        likely to have to deal with those communications in some
        common language and/or script, probably (again, noticing
        world realities outside the Internet) English/
        Roman-based.   So we will make some extensions that will
        work well for communicating within your communities once
        you deploy them (and you have a _lot_ of incentive to
        deploy them) and that will preserve the same level and
        quality of communications that you have today with
        everyone else (no better, no worse) until the rest of us
        catch up... not just with the extension technology, but
        maybe even with learning to read and understand your
        script and/or language.
        
        "And, incidentally, the main alternatives, while they
        might deploy more quickly, are likely to lead to a lot
        of irritated users (who see internal codings because
        their environment wasn't upgraded and no one could tell)
        and/or information loss or other problems."

Now, is this argument correct? I really don't know. But it is one that I don't think we can reject out of hand, especially given the experience we have already accumulated when end users are told they have internationalization and local/native scripts and see internal and incomprehensible encodings in ASCII instead. So I'm trying to explore it, see what it requires, and see if it leads into dead ends and what they are.

Scary? Yes. But I think it would be irresponsible to not take a hard look.

best,
     john