Re: [EAI] The value of simplified downgrade

[John C Klensin <klensin at jck.com>]

--On Saturday, September 12, 2009 00:06 +0800 Yao Jiankang
<yaojk at cnnic.cn> wrote:

>...
>> 1. Sending email to an EAI user ("sending" includes compose
>> new mail,  forward, reply).
>> This case will not have downgrade. If any recipients cannot
>> in fact  receive EAI mail, it will bounce. This is being
>> considered a  'configuration' error. Note this is different
>> from the current Downgrade  spec which supports downgrade to
>> forward pointing addresses.
> 
> If it is ascii user sending message to EAI,  there should have
> a downgrade.

If it an ASCII user (i.e., a user of an ASCII-only environment)
sending a message to an EAI user, then there are only two
possible cases:

(i) The ASCII user has (or can easily obtain) an ASCII address
for the EAI user and can use it in her MUA.  In this case, the
user is doing the "downgrade" and no "downgrade" in the protocol
is necessary or even useful.

(ii) The ASCII user does not have an ASCII address for  the
intended recipient.   In this case, no downgrading mechanism
that we could devise is going to be helpful -- the situation is
hopeless and no message can be sent.   Note that this is really
no different from the traditional situation in which you want to
send some one an email message but don't have an address or a
way to guess one (or have only an address on an internal email
system with no way to guess the mapping from your external
environment, even if one exists).  You are out of luck until and
unless you can use some out-of-band mechanism to determine a
usable address.

> If the SMTP server or MUA has not been updated to support EAI,
> the ascii user can not send the message to EAI account because
> the SMTP server or MUA can not recognize the EAI and will
> regard the EAI address as illegal one. This has been pointed
> out in draft-yao-eai-problem-00.txt.

Yes.  And in several other places.

>> 2. Sending email to an non-EAI user.
>> a. If EAI has downgrade, the user may use his EAI email
>> account. As long  as an alternate address has been
>> configured, the mail will be downgraded  using the supplied
>> ASCII address as the From address. b. If there is no
>> downgrade, the user will have to use his non-EAI email 
>> account. This is slightly awkward, but not be a major
>> hindrance. Many  people are used to managing more than one
>> email accounts, for example one  for work and a second for
>> personal email.

But, if the user has both addresses available, and understands
that the target address is not EAI, then the user can (and
probably should) use his ASCII address as the "From:" address
and backward-pointing envelope (MAIL FROM) address.   If I were
constructing an EAI-aware MUA with multiple identity support,
I'd want to arrange it to support paired identities and to
switch to the ASCII address if any or all of the outgoing
addresses were ASCII.  Note that this does not require any
downgrade support in the protocol.

>> 3. Sending email to a mix of EAI and non-EAI users.
>> a. If EAI has downgrade, the user may use his EAI email
>> account and send a  single message, freely mixing EAI and
>> non-EAI addresses on To, Cc, etc.

Actually, no.  The user must not only be able to mix those
addresses, but must also have alternate addresses for all of the
EAI ones.  Otherwise, if downgrade is needed, it will fail and
the message will be rejected.    For the situation in which all
of the possibly-needed alternate addresses are available, the
sender has two choices, even if downgrade is included in the
protocol:

	(i) Treat the message as all-ASCII, using the alternate
	addresses starting from the point of origin and encoding
	the i18n addresses, if desired, into name phrases or
	comments.  
	
	(ii) Have out-of-band knowledge of the actual
	deliverability of the EAI addresses (as several people
	have pointed out, this is extremely likely if those
	addresses exist and everything is configured correctly).
	This case does not require that downgrade exist or be
	usable.
	
	(iii) Hope that downgrade not only exists in the
	protocol but that it will actually be used properly when
	needed by mid-path software.   Any MUA that takes this
	course of action must, in practice, assume that it will
	fail and be prepared (in some way) to deal with message
	rejection because downgrade support is not a _required_
	element of our protocols even today.  It further needs
	to assume (or hope) that nothing will cause message
	rejection in a relay environment that requires returning
	an NDN and that the NDN will actually be generated and
	not discarded as an anti-blowback "feature".

Note that the first two of these do not require Downgrade in the
protocol and that the third is inherently unreliable.

>> b. If there is no
>> downgrade, the user will have to send the same email  twice;
>> once using the EAI account for the EAI recipients and a
>> second time  using the non-EAI account for the non-EAI
>> recipients.
>> 
>> Note that in 3b, EAI users and non-EAI recipients do not know
>> the whole  list of recipients, and Reply All will not reach
>> the full list (unless the  original sender is very
>> disciplined and copies replies from EAI to non-EAI 
>> recipients and vice versa).
>> 
>> By comparison, in 3a, EAI recipients will see all the people
>> that received  the email and Reply All will reach everyone.
>> However, non-EAI recipients  will not see any of the EAI
>> recipients, and their Reply All will only  reach the non-EAI
>> recipients and the sender. This is a consequence of  dropping
>> double angle brackets on forward pointing addresses, and was 
>> pointed out by Harald as the "triangle" case. As noted in
>> that discussion,  even with double angle brackets the
>> triangle case will not consistently  work in practice, as it
>> depends on users being sufficiently disciplined to  undertake
>> the extra effort of entering alterrnate addresses for all EAI 
>> email addresses.
> 
> in 3a,
> +1, it means that even if the current full downgrade mechanism
> is used,
>  we still can not assure 100% downgrade since the alt-address
> is depending on the user.

That is correct.  If  if the alt-addresses are present, we still
cannot assure 100% downgrade.  Absent specific out-of-band
knowledge about the receiving and intermediate systems, there
are no circumstances in which downgrading is going to be 100%
reliable (I think this is part of the point Shawn has been
trying to make).  Conversely, if one has that out of band
knowledge, downgrading is not needed because all of the relevant
adjustments can be made by the originating user or her MUA.

>  so in this sense, simple downgrade does not differ from much
> the full downgrade.

This is one of the situations that has caused me to want to see
a protocol spec rather than more inherently-vague discussion in
email.  "Simple downgrade" may mean at least the following
different things:

	(i) Downgrade for backward-pointing addresses only
	("MAIL FROM" and "From:"), even if the
	double-angle-bracket syntax is used for the latter.
	
	(ii) Downgrade for backward-pointing _envelope_
	addresses only, perhaps in combination with a
	multiple-valued From: field.  Note that doing this would
	permit return of NDNs even when (or especially when)
	interpretation of the "From:" field linkages is
	uncertain. 

There may be other combinations.  Note that the first risks
leakage, etc., while the second sacrifices unambiguous
Reply-ability to improved deliverability.  

>> Clearly, the pain is case 3b. To the extent that we wish to
>> improve on  this scenario, we should include downgrade.
>> 
> 
> 3b,  is really pain?
> 
> it is similar to business card situation.
> the chinese business card has two sides, english side and
> chinese side.
> english side is only for those who can not under stand
> english; chinse side is for those who knows chinese.

I'm not sure that analogy works, except that, if one finds a
single non-Chinese speaker among the cards, one then decides to
carry out the entire conversation in "English" in the hope that
all of the Chinese speakers also understand English.   That,
again, leads to three cases:

	(i) All of the Chinese speakers do, in fact, speak
	English, all of the cards are turned to the English
	side, and the conversation is carried out in English.
	This is very similar to the "it just gets fixed by the
	sender (or sending MUA) to use nothing but ASCII
	addresses" case above; in-route downgrading is not
	needed.
	
	(ii) Some of the English speakers do not understand
	Chinese and some of the Chinese speakers do not
	understand English.  In this case, the situation is
	hopeless without an intermediate _language_ translation
	function, whether everyone has an ASCII address or not.
	And, if not everyone has an ASCII address, delivery is
	impossible, without or without a downgrade capability.
	
	(iii) All of the Chinese speakers understand English,
	but some of them do not use two-sided cards.  The
	English speaking sender, who does not speak Chinese,
	still has a way to use the Chinese outbound addresses
	for  those users and does so _and_ no downgrading is
	needed en route (since it would fail if attempted
	because not all alt-addresses are present).  Downgrade
	doesn't help with this case for that reason.  And I
	suggest that it will be extremely rare in practice.

>> A second consideration is the effect on encouraging and
>> speeding the  migration to EAI from legacy email systems.
>> Without downgrade, people have  to actively maintain two
>> email accounts.

No.  Without downgrade they have to maintain two email
_addresses_.  Whether those addresses are aliases for the same
account is a local matter -- remember that messages with
non-ASCII body parts work (or not) regardless of EAI.

>> Under this circumstance, they may  just
>> choose the non-EAI account as the primary. With downgrade,
>> there is  an incentive to use the EAI account as the primary
>> account, since it  handles mail for all cases 1, 2 and 3.

Except when downgrade fails to work as expected because some
intermediary rejects rather than downgrading, because there are
other recipients who haven't supplied alternate addresses, etc.

>> One of the assumptions in a simplified downgrade is that it
>> is not perfect  (does not handle every possible case) and may
>> lose some audit trail  information. We need to decide if an
>> imperfect downgrade is still better  than no downgrade at all.

One of the assumptions in a non-simplified downgrade (i.e.,
5504-conformant downgrading) is that it is not perfect and will
not downgrade every possible case and may lose some audit trail
information.  From that perspective, the simplified and
non-simplified cases are not much different.   I think the
questions are whether the simplified (and less complex) form
still buys enough to be worth the trouble... even if we conclude
that the full downgrade form is complex enough, and covers few
enough realistic additional cases, to not be worth the trouble
it requires.  One of the key differences is that senders are
always capable of knowing their own ASCII addresses (if those
exist), but that we have no reliable and general mechanism for
knowing those of all receivers.

> +1, yes. the WG should decide it.

I'm not quite sure how the WG does that.  It is not clear to me
that these discussions are converging.  And, more important
personally, I don't know how I would decide without a concrete
proposal for "simplified downgrade" on the table, presumably as
an I-D, so that I could really try to analyze the cases.

    john