Re: [apps-discuss] Review of draft-ietf-eai-simpledowngrade-03

[Arnt Gulbrandsen <[e-mail]>]

On 04/24/2012 01:23 AM, Ted Hardie wrote:
> Hi Arnt,
>
> Thanks for your quick reply.  I've added the apps-discuss list to the
> distribution; I forgot them on the original, though they are usually
> cc'ed on appsdir reviews.

I wondered about that. "Shouldn't there be a Cc to that mailing list 
that always refuses my reply?"


> I certainly hope that internationalized mail to conventional mail will
> be a corner case,
> but I'm not sure my personal crystal ball is clear enough for me to be
> certain that will be so.

My path to enlightenment was:

Assume that you have EAI and I not. Then your first mail would have been 
the last in this thread. At that point I have two options: Accept not 
replying (in which case the message count stays at one) or upgrade my 
client (which is bothering me to do so anyway, as chance will have it).

How many times will I accept not being able to reply before I either 
shout at you (on the phone) to stop being so $#@$!#@$ internationalized 
or upgrade my own client? Few enough, I guess, that it remains an odd case.

(I'm told this how Microsoft makes people upgrade to new versions of Word.)

> I am not sure*any*  downgrade doc belongs on the standards track, if that helps
> clarify my review.  I think losing security characteristics of the
> sent message in order
> to accomplish post-transformation delivery is a trade-off that raises
> general concerns,
> especially where a signature is present.

Yeah. You could say that's why it was do easy for John to goad me into 
writing this document. I feel that the transition period (when most 
users have only conventional clients but some users send some 
internationalized mail) is bad and ugly and should be abbreviated at 
almost any cost, and therefore implementers should get to work 
implementing EAI proper rather than downgrade.

Maybe -simpledowngrade should mention how wondrously easy it is for an 
IMAP client to learn to read internationalized email? (Sending may be a 
little tricky, but reading really is simple.)

>>> >>  This may eliminate MIME parameters (see section 2.2); it may also
>>> >>  eliminate any header field not explicitly treated (the subject field
>>> >>  and those listed in 2.1).  This, combined with the possible invalidity
>>> >>  of signatures for signed body parts, can significantly reduce the
>>> >>  amount of data available to the user for making a determination of
>>> >>  whether or not a message is legitimate.
>> >
>> >
>> >  You seem to be describing a user who knows much about internationalized
>> >  mail, who corresponds using internationalized mail, but who has no software
>> >  that supports it. Yes, it's hard on that user;)
>> >
> I think I am describing a conventional user more than an internationalized email
> user.  If you have an expectation that an email message should contain
> certain things
> (or your user agent checks for validity by looking for specific
> things), this won't even present
> you nonsense in some places you are expecting sense.  It simply cuts
> the data.  How can
> the user or her delegated software assess that?

How can you assess the validity of an email message which uses new 
syntax? Syntax you don't understand?

For an IMAP client willing to learn the new syntax, the answer is easy. 
Send one ENABLE command (in IMAP) and learn to accept UTF-8 in all the 
places where you only accepted ASCII until now. For someone not willing 
to learn the new syntax, I don't think the question can have any very 
good answer.

>>> >>  Crafting a message that
>>> >>  appeared to have already gone through this encoding also seems
>>> >>  relatively easy, making it possible for a sender to provide a message
>>> >>  that does not have the normal complement of data for assessment by a
>>> >>  user.
>> >
>> >
>> >  The assessment data is generally ASCII now, why would that change?
>> >
> If I craft a message without any of the headers that this allows me to
> excise and with
> .invalid-ed in From and Re-sent From, how can the user or the user
> agent distinguish
> that from the action of the server here?

Why is that task worth supporting?

I can think of an easy way to support it within simpledowngrade (a new 
FETCH item). But issuing the ENABLE command and doing the analysis based 
on the pristine message is just as easy.

>>> >>  The document does not describe how it relates to the other two options
>>> >>  the working group has discussed for downgrade.  I believe it should do
>>> >>  so in order to provide context for the choices made here.  A review of
>>> >>  the mailing list shows this message:
>>> >>  http://www.ietf.org/mail-archive/web/ima/current/msg04539.html   as
>>> >>  kicking off the core rationale and relationship.   Some form of this
>>> >>  should be included in the document, possibly along with the "no
>>> >>  downgrade" option.
>> >
>> >
>> >  I haven't added anything like this, because I'm not sure which document
>> >  should contain it.
>> >
>> >  I'll happily supply text.
>> >
> Thanks.  A pointer to text in another document would be equally valid.

My gut feeling is that we'll end up with an overview document of some 
sort which links to both downgrade documents, and that that document is 
the right place. But I confess I haven't tried to work out what that 
means in concrete terms.

>> >  Would you be happy if the document specifies explicitly that the stored form
>> >  has to be the original message, not the synthesised form?
> Yes, I think that would be a useful addition.

OK.

Arnt