Re: [EAI] Downgrade Design Team Discussion Results Released

[Shawn Steele <[e-mail]>]

Yippee, when can we expect an updated draft of a new charter then?

-Shawn

----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Mar 2010 14:45:22 +0800
From: "YAO Jiankang" <[e-mail]>
Subject: [EAI] Downgrade Design Team Discussion Results Released
To: <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"

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.