Subject: Re: [EAI] EAI review topic: Parameter on MAIL command

From: Yangwoo Ko <[email-masked]>
Date: Wed, 29 Dec 2010 17:00:30 +0900

I prefer an option that looks simplest in a situation where all
servers are upgraded to be compliant to these new specifications. In
that sense, I am negative to adding a parameter to MAIL command to
handle (hopefully very rare) situations of encoutering an un-upgraded
server. Since most of recent comments received by this WG recommend
adding the option, I am not strongly against the idea because the
modification will not significantly affect the current document.

On Tue, Dec 28, 2010 at 9:12 AM, John C Klensin <[email-masked]> wrote:
>
>
> (writing as co-chair)
>
> Hi.
>
> Joseph and/or I will be sending out a series of (short) notes to
> the WG mailing list identifying substantive issues that the WG
> needs to review and make decisions about.  They are going to be
> short in the hope that people will read them and read them soon,
> but there are relevant previous discussions on the mailing list,
> in the reviews, and in the long set of notes I posted earlier
> that people should try to understand before responding to the
> questions.  However, remember that the WG is supposed to be
> working quickly: these issues are in the critical path for
> anything to more forward.
>
> Question: Should we define, and require, an announcement
> parameter on the MAIL command if the sender intends to transmit
> either non-ASCII addresses or UTF-8 in headers (other than as
> encoded words)?
>
> Discussion references: My long note, especially item (2), which
> I hope summarizes the review comments) and a number of comments
> on-list about what is required if this header is not present.
>
>    john
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

-- 
a human known as [email-masked] @ gtalk

---

From: [email-masked]
Date: Thu, 30 Dec 2010 10:22:45 -0800 (PST)

> servers are upgraded to be compliant to these new specifications.

Unfortunately, past experience has shown us that considering the end point
without also considering the path to get there is often a prelude to a failure
to deploy.

Believe me, I wish it were otherwise - it would have made MIME cleaner and
simpler, for one thing.

> In that sense, I am negative to adding a parameter to MAIL command to
> server.

This point won't be reached any time soon. In fact given how many email
implementataions are now baked into various infrastructure pieces, it's more
likely we won't get to this point for a very, very, very long time. And that
makes it very important to have a viable transition and coexistence strategy.

> Since most of recent comments received by this WG recommend

Speaking as an implementor, the presence of this parameter should let us avoid
avoid having to perform deep inspection of messages in almost all cases. And
while we already support deep inspection capabilities for a number of other
reasons, it's sufficiently expensive that we ship with any options depending on
it disabled by default. That would mean that without this parameter anyone
wanting to use EAI will have to explicitly enable it, which definitely isn't
going to help get this deployed.

				Ned

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 31 Dec 2010 10:17:53 +0900

On Fri, Dec 31, 2010 at 3:22 AM, Ned Freed <[email-masked]> wrote:
(snip)
> going to help get this deployed.

This point really makes sense to me.