Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 17:55:16 +0000

Since you have no objection, I suppose my reply is irrelevent, however:

IMO saying "UTF8SMTP" or whatever describes the behavior of EAI.  "Extending" EAI to another encoding is a non-starter.  Other extensions may be useful, but I don't see how adding EAI parameters helps as we cannot foresee the direction of the extension, and it's out of the scope of the WG to (re)define extension methods.  I don't see needing EAI-specific extensions in the future, though I could be short-sighted.

I suppose if we had a "Human languages the user can read" extension to facilitate machine translation, or at least correct selection of response language, that could include "LANGUAGES: en, de, es", then perhaps there'd be an international-related extension to the standard.  Even in that case, I don't see why it couldn't have it's own "LANG" extension with whatever syntax that extension needed.

Assuming we really screw up EAI and need to "fix" it, we always have the option of changing the tag to "UTF8V2" or something.

-Shawn
------------------------------

Message: 2
Date: Tue, 18 Jan 2011 12:01:19 -0800
From: Troy Starr <[email-masked]>
Subject: Re: [EAI] To: "[email-masked]'" <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Shawn -

While I don't think I have the same zeal about character encodings, I appreciate your concern.  I don't think the working group should spend a significant amount of time trying to think about how the standard might be extended, but I still think it's valuable to acknowledge that it might happen for reasons that aren't obvious to us today.  And if we can design our parameters to be more friendly to potential future extensions with minimal cost and no negative impact on implementing this standard, then I think it would be wise for us to do so.  We don't need to concern ourselves with whether those future extensions are good ideas - that can be safely left to future working groups who wish to propose those extensions.

And as I said, while I would prefer the type of design I've described, the other proposals that have been given also meet the goal of this working group and I would have no objection to them.

- Troy Starr

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Jan 2011 13:33:00 -0500

--On Wednesday, 19 January, 2011 17:55 +0000 Shawn Steele
<[email-masked]> wrote:

> IMO saying "UTF8SMTP" or whatever describes the behavior of
> EAI.  "Extending" EAI to another encoding is a non-starter.
> Other extensions may be useful, but I don't see how adding EAI
> parameters helps as we cannot foresee the direction of the
> extension, and it's out of the scope of the WG to (re)define
> extension methods.  I don't see needing EAI-specific
> extensions in the future, though I could be short-sighted.
>...
> Assuming we really screw up EAI and need to "fix" it, we
> always have the option of changing the tag to "UTF8V2" or
> something.
>...

Right.  Although I assume that "UTF8V2" would cause us terrible
problems about whether we really intended a new version of UTF-8
and "or something" would be chosen.

More generally, there are two types of "extensions to EAI",
those that are really extensions and those that head off in
another direction.  There are also lots of in-between cases, so
the decision would be a judgment call.   Either way, that can be
done either by an additional extension keyword that requires EAI
as a prerequisite (as we have done with 8BITMIME) or a separate,
presumably orthogonal, extension.  

But, in my interpretation of Shawn's comment, let's not make
trouble for ourselves.   Paraphrasing a comment that was carried
forward into RFC 5321, we've had lots of experience that
extensions and features that are simple and that have few or no
options deploy well and without interoperability problems while
features that are more complex, with many options, tend to have
lots of trouble.  

The WG has explicitly decided on several occasions to try to
keep things simple and option-free: UTF-8 only rather than
allowances for other charsets in header fields, dropping
downgrading and alternate addresses, and so on.  Let's keep it
that way with one EAI, one set of specifications to which
everyone either conforms or does not, and so on.  We can all
invent plausible variations to cover theoretically-plausible
cases.  But let's not.

    john