[EAI] Downgrade Design Team Discussion Results Released

["YAO Jiankang" <[e-mail]>]

Dear all,

   The design team has several jabber meetings and reached a conclusion.
With the permission from co-chairs, I send the Design Team Discussion Results to WG for review and comments.
We will discuss this result and hope to get some consensus for downgrade during our meeting in Anaheim.
any comments are welcome.

below is the Design Team Discussion Results: (or see the attachment)
------------------------------------------------------------------------------
The EAI Downgrade Design Team was created to investigate the
problems around EAI downgrade.  The Design Team's conclusion is
that downgrade should be removed from the core docs.  This
allows the EAI WG to focus on moving the core RFCs to standards
track immediately, without being blocked by downgrade.
Alternatives to downgrade have been discussed, but the Design
Team recommends any further work be restricted to a
MUA/submission protocol independent of the core transmission
documents.

For precision, the terminology used in this document is
summarized at its end. 

The goal of the EAI Downgrade Design Team was to unblock the
discussion of downgrade to enable progress on the EAI
standards.  A key factor is a strong desire to move the core
documents to standards track.  Extensive debate of downgrade
could obstruct the rest of EAI for the foreseeable future.

The EAI Downgrade Design Team reached this conclusion by
examining the results of the current downgrade experiment and
the discussion and suggestions of the EAI working group.  We
grouped the possible approaches to backwards legacy SMTP
compatibility into three buckets:

1) Declared address pairs, eg: Alt-Addr.  This is the approach
   described in RFC5504 (downgrade) and variations on it.

2) Discoverable fallback address.  This includes any
   MUA/submission server protocol that derives ASCII addresses
   from a Unicode address for resubmission by legacy SMTP.  It
   also includes other algorithmic techniques, lookup of
   alternate addresses in local address books, and those using
   protocols external to SMTP processing to find those
   addresses.  The key characteristic of this bucket is that
   there is no downgrading of messages in transit; changes to
   addresses or other information are made only at the
   originating MUA or submission server, typically in response
   to external knowledge or some information received by them
   such as an NDN.  This bucket does not require Alt-Addr
   parameters, header address syntax to support them, or other
   dependencies on legacy compatibility strategies in the core
   transmission protocols. 

3) No fallback.  This devolves into "messages with
   undeliverable addresses are rejected", i.e., the
   traditional SMTP model.  A user, or programs acting on the
   user's behalf, can, of course, alter or resubmit the
   message with different address information.

Declared address pairs (e.g., with Alt-Addr) have been ruled
out as a possible solution.  The RFC5504 experiment was
invaluable in revealing the limitations of a paired address
system.  While the idea of friendly alternate addresses is
attractive, the Design Team concludes that paired address
mechanisms are inherently fragile.  The pairing has innate
problems with lost pairs, mismatched pairs, possible spoofing,
and failure in some cases.  Additionally, the extensions
provided by RFC5504 cause problems for some legacy mail
systems.

Discoverable fallback address mechanisms are potentially
interesting because they can always be determined by systems
aware of the discoverability convention.  However, discoverable
fallback address mechanisms do not require Alt-Addr and do not
have to be visible in the core documents.  There has been a lot
of discussion about the practicality of the proposed mechanisms
for discoverable fallback; we expect that those discussions
will continue, but that they will do so outside the critical
path.

In theory, discoverable fallback addresses could be discovered
by a relay server rather than at the MUA/submission server.
This approach was deemed impractical; it requires too much
coordination between parties that do not have communication
with each other.

No fallback is a technically "simple" solution.  It also does
not require Alt-Addr and requires no consideration in the core
documents.  The submission server may still resubmit using SMTP
if available.

By ruling out "declared address pairs" solutions as
impractical, and by removing any support for "downgrading at
relays", we remove the dependency of the core documents on
specific downgrade models.  This allows further progress on the
core documents by the working group.

The Design Team recognizes that "no fallback" provides a very
minimal transition mechanism, however we feel that "no
fallback" is better than allowing downgrade to block further
progress.  By supporting "no fallback" as the immediate
solution, we still allow for a "discoverable fallback address"
mechanism, should one be proposed.  However the Design Team
recommends that any such investigation to be independent of the
work on to finish the core documents.

In conclusion, the EAI Downgrade Design Team recommends:

o That we immediately recharter EAI to focus on the core
  standards track documents, i.e., RFC4952bis, RFC5335bis,
  RFC5336bis, RFC5337bis, RFC5721bis, and the in-progress
  drafts. 

o RFC5504 should be deprecated.  The core documents will not
  rely on fallback or downgrade techniques, particularly by
  relays.

o Discoverable fallback addresses may be investigated
  independently of the core documents.  Any such work would be
  part of, or connected to, an optional MUA/submission
  protocol, independent of the core transport documents. 

The design team also noted that an informational RFC regarding
selection of addresses (both Unicode and ASCII) would be
helpful, that clients SHOULD use Unicode Normalization Form C,
and that servers MUST use NFC.

Definitions:

Core Documents - RFC4952bis, RFC5335bis, RFC5336bis,
RFC5337bis, RFC5721bis, and the in-progress drafts, excluding
"downgrade".

Submission System - The user, sending MUA or submission server.

Fallback - A mechanism where the submission system attempts to
  resubmit mail using legacy SMTP if UTF8SMTP is rejected or
  returned as undeliverable.

Downgrade - RFC5504 style mechanisms that intend to ease
  transition between legacy SMTP systems and UTF8SMTP systems.

In-transit - message or address transformations performed in
  SMTP transport, after the message leaves the Submission
  Server and before delivery to the Final Delivery Server (as
  defined in RFC 5321), such as by relays.