ietf-smtp
[Top] [All Lists]

Re: email-arch -- comments solicited on I8N

2008-03-11 03:07:16


<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
 
given that the only document out of EAI that has made
it to RFC status is an informational overview

The next two EAI Last Calls started yesterday, there can
be four EAI RFCs soon.

And once there are it will take considerable time for the experiment to even
start in a meaningful way, assuming it ever does.  The email architecture
documeent is needed now and shouldn't have to wait for any of this. It can
always be revised later to reflect the extent to which EAI becomes a reality.

  I'm very curious what you think
about the one or two "experimental MIME updates" in the
EAI I-Ds.  For one (= ignoring an "expressly forbidden")
I think it is actually only a subtle error in RFC 2045.

I'm well aware of this issue, and I disagree completely with your
chararacterization of this as a "subtle error". The fact of the matter is that
nested encodings were extremely contentious issue at the time MIME was created
and we were well aware of the consequence - both short and long term - of
including this restriction. It was quite simply the only possible path forward.

It may be that the time has come to remove the restriction. Or it may  not. But
no matter how it plays out, the reality is that without this restriction MIME
would not have made it out in a usable form. This choice is therefore  a lot of
things, some of them not especially nice, but "subtle error" isn't even close
to being on the list.

For the other (= UTF-8 in MIME part headers) I fear it
could cause havoc, and is unnecessary for EAI.  Please
tell me that this is a hallucination on my side, and no
real EAI design issue.

It could go either way, alrhough my guess is the real issues with EAI will turn
out to be things none of us anticipate now. For example, I'm very concerned
about how EAI will interact with existing antispam mechanisms. A widespread
conflict in this regard could render it effectively undeployable. I'm also
curious to see to who will want this and where.

All of these things are part and parcel of why EAI has been cast as an
experiment.

But really, none of this is in any way relevant to the matter at hand, which is
getting the email architecture document done and out the door. You may believe
that holding up this document in order to get EAI into it makes sense, but I
quite simply disagree.

                                Ned