Subject: [EAI] adjusting framework?...

From: "Edmon Chung" <[email-masked]>
Date: Mon, 17 Jul 2006 15:11:53 -0400

It seems like there is interest perhaps for looking at adjusting the framework or approach architecture... here is a very brief summary of what I think I am hearing (on SMTP only for now):

EAI-aware MTA/MUA --send-to--> EAI-aware MTA
- envelope: UTF8 addresses
- headers: UTF8 headers

EAI-aware MTA/MUA --send-to--> non-EAI-aware MTA
- envelope: EAI-ACE addresses
- headers: rewrite with EAI-ACE and MIME
- encapsulated downgrade info in new MIME content type

(as comparison, an outline of the current framework as I understand it is included further below)
In the above, neither ATOMIC or ALT-ADDRESS is required.  However it assumes that there is going to be a standard universally reversible EAI-ACE.  An "improvement" with this from the current framework is that the protocol does not create a scenario whereby the existence/use of an i18nemail address causes a failure/bounce back (whereas the current framework does --> i.e. when downgrade info is not available... i.e. when neither ATOMIC or ALT-ADDRESS info is available).

I however actually like the ALT-ADDRESS feature though... so if possible I would propose the following:

EAI-aware MTA --send-to--> EAI-aware MTA
- envelope: UTF8 addresses WITH OPTIONAL parameter to specify ALT-ADDRESS
- headers: UTF8 headers WITH OPTIONAL parameter to specify ALT-ADDRESS

EAI-aware MTA --send-to--> non-EAI-aware MTA
IF alt-address info is available, THEN:
- envelope: ALT-ADDRESS
- headers: rewrite with ALT-ADDRESS and MIME
- encapsulated downgrade info in new MIME content type
ELSE:
- envelope: EAI-ACE address
- headers: rewrite with EAI-ACE and MIME addresses
- encapsulated downgrade info in new MIME content type

This approach also assumes that a standard universally reversible EAI-ACE is designed.

The big question however is who will design this EAI-ACE?  A few have stated it should be possible, also there were some who were suspicous that it could be done...

Edmon

PS.  Just for comparison, the following is what I understand the existing framework to be:

EAI-aware MTA/MUA --send-to--> EAI-aware MTA
- envelope: UTF8 addresses with OPTIONAL parameter for specifying: ATOMIC or ALT-ADDRESS
- headers: UTF8 headers with OPTIONAL parameter for specifying: ATOMIC or ALT-ADDRESS

EAI-aware MTA/MUA --send-to--> non-EAI-aware MTA
IF ATMOIC = yes, THEN:
- envelope: EAI-ACE address
- headers: rewrite with EAI-ACE and MIME addresses
- encapsulated downgrade info in new MIME content type
ELSE IF alt-address info is available, THEN:
- envelope: ALT-ADDRESS
- headers: rewrite with ALT-ADDRESS and MIME
- encapsulated downgrade info in new MIME content type
ELSE:
- bounce mail / send failure (downgrade cannot be performed)

During the Montreal meeting, the following was essentially suggested:

EAI-aware MTA/MUA --send-to--> EAI-aware MTA
- envelope: UTF8 addresses with OPTIONAL parameter to specify ALT-ADDRESS
- headers: UTF8 headers with OPTIONAL parameter to specify ALT-ADDRESS

EAI-aware MTA/MUA --send-to--> non-EAI-aware MTA
IF alt-address info is available, THEN:
- envelope: ALT-ADDRESS
- headers: rewrite with ALT-ADDRESS and MIME
- encapsulated downgrade info in new MIME content type
ELSE:
- bounce mail / send failure (downgrade cannot be performed)

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