Subject: Fw: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 11 Apr 2007 14:20:55 +0800

forwarded it as it is.
----- Original Message ----- 
From: "Yuri Inglikov" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 11, 2007 1:56 PM
Subject: RE: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt

I am trying to catch up on the progress of this WG and wondering if the following was ever debated or not. The downgrading with Downgraded: and Envelope-Downgraded header fields apparently has the following issues:

1. Address header fields (such as To, Cc,...) going out of sync with corresponding Downgraded: header fields. There are applications which modify address header fields, such as address rewriting agents or workflow applications. This means that upgrade of address header field may not always be possible. I think that the method which is based on introducing unstructured redundant information like this is flawed. My preference, if we need to keep a path to upgrade header fields, would be to do this on a per-recipient basis and just drop the Downgraded: information if corresponding recipient not found in any address header. Also we should introduce as little redundancy as possible, e.g. there is no need to duplicate display names in Downgraded: header as display name can be safely 2047-encodded without data loss.

2. Some MUA potentially can preserve the Downgraded: header fields in replies and especially in forwarded messages. While this may not be a problem for RFC2822 or MIME header fields (it is not worse than original header field being preserved), the net result is that such Downgraded: headers can appear in a wrong message, i.e. not the one which was originally downgraded. This, on the first glance, can be a real problem for Envelope-Downgraded headers, e.g. MAIL FROM address, is it? E.g. could it cause P1 sender of a message being replaced with original sender while upgrading the envelope information? Is there such thing as envelope information upgrade? If not, then why bother preserving such information (other than as another trace field)?

I personally think that it can be acceptable to define the downgrade process as not reversible, e.g. that downgrade can just drop the UTF8 address and use alt-addresses instead. There should be no such thing as upgrade, the downgraded message should be handled as normal pre-EAI message with appropriate information encoded in a backwards-compatible fashion. What are disadvantages of this approach? I assume we want the downgrade mechanism to be less and less necessary over time when everybody upgrades to support EAI.

My another feeling is that unknown header fields downgrade can just use RFC2047 encoding by default. The reasoning is that no header fields defined before EAI are supposed to contain UTF-8 and no downgrade should be necessary for such header fields, except those specifically supported by EAI (such as Subject, address header fields). Of course new header fields can be defined after EAI is introduced which may want to take advantage of UTF8. In such case they either should be defined as unstructured headers for which default downgrade mechanism (RFC2047) is sufficient, or those are new structured headers. For new structured headers EAI could define a way to identify such header for EAI downgrade purposes and a common open format (like the one defined for a Content-Disposition header with parameters) with provisions how to identify parts which potentially can contain UTF8 and how to downgrade them (RFC2231?).

I.e. then downgrade process could be defined as dropping redundant information (UTF8 addresses) and orderly encoding of remaining UTF8 information. No upgrade process should be defined.

Sorry if I am bringing back something which was already debated and rejected, I still have a lot to catch up.

Thanks,
Yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 10, 2007 7:22 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt

> From: John C Klensin <[email-masked]>
> >> For some reason, we decided to use "rejected", rather than
> >> "bounced".
> >
> > fixed.
>
> Please be careful about this so as to not introduce new
> problems.  "rejected" is intended to imply "detected during the
> receiving function of the SMTP system and handled by sending a
> reply code back to the would-be sender".   Unless the downgrade
> machinery is invoked before the connection from the sender is
> closed, any notification to the sender that downgrading is not
> possible will have to be sent as a DSN, not a provided in a
> "reject" context.  While it would be possible to do so in at
> least some cases, in general trying to keep that incoming
> connection open until it is determined whether successful
> downgrading can be accomplished would not be a good idea.

I understand.

I deleted "rejected" and rewrited as "Downgrading fails".
After failed downgrading, the message will be bounced but it is
written in smtpext document.

--
Kazunori Fujiwara, JPRS

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

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