Subject: Re: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade-02

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 02 Apr 2012 10:07:06 +0900

On 2012/03/29 23:13, John C Klensin wrote:
>
>
> --On Wednesday, March 28, 2012 17:17 +0200 Barry Leiba
> <[email-masked]>  wrote:
>
>>> There is at least one exception. Section 2.3 (about Subject)
>>> does not (yet) end with "[RFC2047], perhaps adding a prefix
>>> or suffix to inform the user of the downgrading." Alexey
>>> wants it, and I think one other person did too? Martin? I
>>> know I'm being sloppy about names.

Yes indeed. See below.

>>> Anyway. I'll add it if there's support. Personally I'm
>>> against it, since the downgrade process is largely harmless
>>> except when the user wants to reply, and when the user wants
>>> that there are clear markers on every affected address.
>>
>> I'm very much against it.  We can "downgrade" (actually,
>> encode; there's no real downgrading going on here) the subject
>> with NO loss of data and NO ugliness.  Let's not screw that up
>> by making it ugly on purpose.
>
> Agree.  As a general guideline, I think that it is reasonable to
> make any translation or transition that can be made with no loss
> of information without adding notes.  In addition, adding notes
> to Subject lines after they are transmitted is a bad idea
> because the recipient has no idea where the note came from (take
> the number of perfectly good messages that arrive with "[ s p a
> m ]" in the subject line as an example).

That's of course annoying, but there are usually way more messages with 
[ s p a m ] in the subject line that are actually spam. Speaking only 
from my personal experience, such a header actually improves my 
processing speed even if there are occasional false positives. Of course 
your millage may vary.

> If people think they need a note that transformations were
> applied, let's mandate doing it with a track field ("Received:"
> or otherwise is a separate discussion) that explains that
> something was done and by whom.    And that part of the
> behavior, fwiw, should preferably be uniform between simple and
> not-simple downgrading.

I don't mind adding a track field, if that's what others want. But for 
whom is that? There are three possibilities:

- The MUA: This doesn't apply, because I don't think there will be many
   MUAs that deal with downgrading. If anybody wants to spend work on an
   MUA, just work on the upgrade.

- A human debugger: These are few and far between. Not every family has
   a resident email 'expert'. And if they have such an 'expert', that
   person may be able to fix setup glitches, but not much more. Humans
   have a tendency to imagine that others are like us, but usually that's
   not at all the case, in particular when it comes to something like
   email experience.

- The actual user: For the actual user to notice something, there has
   to be a change in one of the fields that are displayed in the average
   folder overview. Now From is changed, and that's usually displayed,
   but that doesn't count because an EAI address may be seen for the
   first time. This is in particular important in a scenario where
   the user reads mail only from one device/MUA, or all devices/MUAs
   are non-EUA-aware.

That's why I think it should be *allowed* to tweak the subject. IMAP and 
POP server developers can still make the choice to not implement it, or 
to leave it configurable.

Regards,    Martin.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 2 Apr 2012 08:56:22 +0200

> That's of course annoying, but there are usually way more messages
> with [ s p a m ] in the subject line that are actually spam. Speaking only
> from my personal experience, such a header actually improves

There's a big difference between labelling messages you want to filter out,
such as spam, and labelling messages that the *user* just wants to read
without annoyance or encumbrance.  The user doesn't care about downgrading;
the user just wants to read the messages.

> The actual user: For the actual user to notice something, there has
> folder overview.

Explain why the user wants to notice anything.
My mother wouldn't understand what was going on, and would only be annoyed.
She might call her ISP's help line, which would be a disaster on anything
more than a tiny scale.

> to leave it configurable.

The problem is that this is a configuration decision for the client, not
for the server, but by altering the subject you're having the server make
the choice.  Bad.  And by definition, the client can't do it, because this
is specifically for old clients that don't understand.

Please let's leave this alone.

Barry

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 02 Apr 2012 16:20:20 +0900

Hello Barry, others,

> the user just wants to read the messages.

On first approximation, I agree. But next, the user may want to reply.

> She might call her ISP's help line, which would be a disaster on anything

She may call her ISP's helpline if there's some special tag. Or she 
might not. But then she'll try to reply, and that won't work. Then a 
call to a helpline has a rather higher probability. And then, the same 
thing (not being able to reply) might happen again a day later, or a 
week later, or a month later, or what not. It will become very annoying 
to try to reply but not have it working.

It may be easier (it would definitely be easier for me, but of course, I 
don't want to claim that I'm in any way representative) to understand 
what's happening if all the mails that can't be replied to have the same 
label.

Also, imagine the call to the ISP. If she complains that she wasn't able 
to send, the helpline staff can ask "did the Subject say [foo]"? If yes, 
they already know the answer in most cases. Without a label, they'll 
have to ask all kinds of questions, many of which will be difficult 
because of privacy concerns, and that will take time.

I never worked at an ISP, or at a helpdesk, so I can't judge what's 
better, but it doesn't look so clear to me that no label is always better.

> is specifically for old clients that don't understand.

I agree that it's suboptimal that the server has to make the choice. But 
I'd still think it's better than the user not having any information at 
all, or the server not having a choice.

Regards,   Martin.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 2 Apr 2012 09:43:46 +0200

With my document editor hat off: I'm now against even allowing changes
to Subject, since I think it's a) not helpful to those users who have
several clients and know which one(s) support(s) internationalized mail
and b) confusing to many of the others.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2012 12:55:30 -0000

>and b) confusing to many of the others.

Does that include changing straight UTF-8 to =?utf-8?B?<base64>= ?

I can see arguments for and against, somewhat separate from changes
that change what the user is expected to see.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 2 Apr 2012 15:00:24 +0200

> Does that include changing straight UTF-8 to =?utf-8?B?<base64>= ?

Sorry, that was carelessly phrased. No. I meant substantive changes, not
the RFC2047 encoding already specified in the draft.

Arnt