Subject: [IMA] Re: draft-downgrade-00

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 27 Oct 2005 22:49:50 +0100 (BST)

As usual, the main principles are fine, but a couple of issues and
various niggles.

1. You speak at various places of downgrading things which are not
addresses by encoding with base64 with UTF-8 tag.

I presume this refers to encoding according to RFC 2047, in which case
please say so and give a reference to RFC 2047 (though RFC 2231 also
extends RFC 2047 and should be mentioned). Moreover, if it is RFC
2047, then the encoding can be Quoted-Printable as well as base 64
(and in some languages Q-P is better). OTOH, if you did not mean the
refer to RFC 2047, then I do not understand - please explain. RFC 2047
is an ugly beast, but at least nearly every MUA knows how to upgrade
it.

You also need to bear in mind that RFC 2047 can only be used in heades
which are 'unstructured' (but that automatically includes all
X-headers), or in <comment>s and <phrase>s. But there are plenty of
other 'structured' headers which have been defined and in which UTF-8
might be useful, but for which RFC 2047 could not help (except within
<comment>s).

Examples are Content-Type and Content-Distribution, where I think you
should mention that RFC 2231 provides a means of downgrading for
<value>s (in <parameter>s); and the various List-* headers, many of
which make use of URIs - in an I18N message, these would be sent as
IRIs, but could be downgraded to URIs.

2. But there will still be headers where no downgrade method is
available, in which case we need a general-purpose downgrade
mechanism.

It has been suggested that encapsulating the whole message could get
around that problem, but I can see problems there, since any Received
headers with UTF-8 in them should really remain outside the
encapsulation (for if they did not, then further Recevied headers
added after the encapsulation would be separated from them, and you
might even find a situation where you needed to encapsulate again).

So let me suggest an alternative general purpose downgrading method.
Suppose we define a new header:

    Header-Tunnel: (whose syntax is just <unstructured>)

Then if you have a structured header
    Some-Header: {stuff with UTF-8 in it}
You replace it by
    Header-Tunnel: Some-Header: ?=utf-8?{UTF-8 stuff 2047-encoded}=?
with the intention that anyone who wanted to upgrade it would simply
decode the 2047 stuff and throw away the "Header-Tunnel: ", leaving
the original header behind.

This would not work for any header which needed looking at during the
transport process (so it might not be a good idea for To: and Cc: and
such like - but we already have downgrades for those). But it would be
fine for headers intended to be read by humans, and even an MUA that
did not understand the "Header-Tunnel:" header would display somethng
that a human could understand.

And now for the niggles:

3.In your section 4.3, I think you need to say that domains and
addresses in Received headers (e.g. in By, From and For) need to be
downgraded using ACE/IDN. You certainly cannot use RFC 2047 on the
whole of a Received header, because it is a 'structured' header and
RFC 2047 does not allow that.

4. I like the idea, in 4.4, of an "IMA-Downgraded" header (but it
could not be "X-IMA-Downgraded" because you are not allowed to
standardize an "X-" header. However, what happens if there are several
headers with the same header-name? How can you tell which of them have
been downgraded and which are as originally sent? That could easily
happen with Received headers, and also with Keywords.

Also, it needs to be mentioned that your Envelope-To and Envelope-From
might look different with a non-SMTP transport with a different
concept of "envelope".

5. In 5,1, I think you need some mention of "upgrading", if only to
say that transports SHOULD NOT do it, but only the "final destination"
(which might be the MDA or the MUA or a gateway or a mailing list
expander - this is an area we will have to discuss further).

6. And I do not understand your 5.2 at all. I think I would expect
that for an MDA to upgrade would be quite a useful feature (but maybe
configurable at the request of the owner of the mailbox). But, as
said, this needs much more discussion.

Charles.

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2005 14:32:40 +0200

A better question might be:

Is a message ever - EVER - upgraded from "normal SMTP" to UTF8HEADERS?

The world would be a simpler place if the answer was "no".

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Oct 2005 09:14:45 -0400

--On Friday, 28 October, 2005 14:32 +0200 Harald Tveit

> The world would be a simpler place if the answer was "no".

My own conclusion, at least so far, is that "upgrade" is
basically impossible unless one carries a large amount of
information around that would have to be specially handled in
both the originating MUA and in any server doing downgrades.  It
would also require either separation of trace information into
the envelope (for the record, the I-D I wrote about how to do
that was an exploration into what would be required -- I didn't
believe it was a good idea then and don't believe it would be a
good idea now) or even more structure.  I've worked up the
latter on a whiteboard and can go through it if someone really
cares, but it leads to various bad places.

A more simple version of this is that we concluded with 8BITMIME
that, if downgrading occurred, that was the end of it and there
should be no attempt at an upgrade.  As far as I can tell, all
of the reasons for that apply here too... and there are some
additional ones.

     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 29 Oct 2005 23:18:50 +0100

On Fri, 28 Oct 2005 14:14:45 +0100, John C Klensin <[email-masked]> wrote:

> both the originating MUA and in any server doing downgrades.

Please can you explain further why that should be so. I think it is  
essential for our scheme that an acceptable upgrading should at least be  
*possible*. What is "acceptable" needs discussion, of course. It does not  
necessarily mean recovering every byte of the original exactly as  
originally written. But clearly every bit of text in the original should  
appear in some form, though maybe not in exactly the same charset and  
maybe not encoded (if at all) exactly as before. And the headers added in  
the downgrade should probably be left.

But I think we need to consider exactly what the limitations on upgrading  
would be, if only to ensure that the downgrading we specify does not make  
subsequent upgrading more difficult than it needs to be.

>  It
> the envelope

Again, it would help if you could explain that further (at least an  
example to illustrate that there is a problem).

Having said that, however, the matter of whether upgrading CAN be done is  
entirely separate from whether, when and where it SHOULD be done.

For sure, it would be pointless to do it during transport (at the SHOULD  
NOT or even MUST NOT level). It it happens at all, it should be when the  
message has arrived at its "destination", however that is defined.  
Essentially, it is up to the recipient how he would like his message dealt  
with. But since the MDA is really acting on behalf of that recipient, we  
cannot ignore MDAs. If the ultimate recipient has contracted with the MDA  
to provide him with POP3 and/or IMAP mailbox(es), then it is reasonable  
for him to ask for his mailbox to hold (or at least appear to hold) an  
upgraded form of the message. Moreover, the WG will have to face this when  
it comes to proposing upgrades for the POP3 and IMAP standards.

And then gateways, mailing list expanders, and other examples of special  
processing should be able to decide for themselves whether to upgrade  
before passing it on.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5