Subject: [EAI] Algorithmic Downgrade

From: Shawn Steele <[email-masked]>
Date: Mon, 14 Sep 2009 07:25:18 +0000

My current thinking is that:

1) Partial downgrade is worse than no downgrade.  Edge cases like this make the behavior difficult to predict, whereas with no downgrade users know to exchange their friendly-ASCII address.

2) I think that a downgrade solution cannot be sufficiently complete for cases like this unless it is algorithmic (eg: unmapped punycode/ACE).

I can think of a few cases where even an algorithmic downgrade may break down (user can't type the letters, email client doesn't support EAI, but that's all the user has, addresses in the text body of a message (eg: not in a header so they didn't get downgraded) and no available EAI client)  Some of those don't always work today though.  Some could be mitigated by an algorithmic web-based mapping tool.

Other automated systems besides algorithmic would include:
* Address pairing, either multiple from, or <<>> type pairs.  <<>> doesn't work everywhere (mailto:) and both get hard to keep the pairs together.  We've already found numerous problems with these schemes.

* Mappings queried from the server.  Connectivity issues make this less reliable than algorithmic mappings.  (Firewalls, port blocking, intermittent network access, etc., make that less robust.)  It also seems more complicated to me on the surface to impliment.

Again: I don't think that an algorithmic fallback should be "preferred" ASCII mailbox.  I think that a human friendly ASCII address is necessary for many EAI accounts.  (Although I can imagine cases where maybe a business needs multiple non-ASCII script addresses as well.  Say Mongolian + Chinese.  Or Chinese + Arabic.)  Anyway, my proposed algorithmic mapping is a worst-case machine fallback address.

About the only problem I can see with an algorithmic technique is that users would have 3 aliases for the same mailbox, however any EAI aware app should be able to discover that the algorithmic ASCII address and the Unicode address are equivilent.

FWIW: An algorithmic alias need not replace other fallback techniques, though I'm not sure they'd add much value if there was a well known algorithmic approach.

At least 2 vendors that own both servers and clients that are independently considering algorithmic generation of ASCII aliases just because it's easy for them internally.  (Not that they'd necessarily interoperate.)  It's not clear if either would provide additional human friendly aliases.

If a hypothetical "shawnMail" hosted mailboxes with this technique and also provided web client access, it'd be a fairly complete closed solution.  If it was one of the big mail providers, I could easily imagine 3rd party or open source clients adding similar support or supporting major providers' algorithms as a competitive or convenience feature.  Rather than having 5 different algorithms for major providers, it'd be nice if there was a common technique.

Even if algorithmic alias generation wasn't a MUST or formal part of the spec, it'd be nice if there was a common algorithm providers MAY use if they think that approach is interesting.

-Shawn

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 14 Sep 2009 17:12:26 +0800

> ----- Original Message ----- 
> From: Shawn Steele 
> To: [email-masked] 
> Sent: Monday, September 14, 2009 3:25 PM
> Subject: [EAI] Algorithmic Downgrade
> 
> 
> 1) Partial downgrade is worse than no downgrade.  Edge cases like this make the behavior difficult to predict, whereas with no downgrade users know to >exchange their friendly-ASCII address.

even in full downgrade, there is also a edge case similar to simple downgrade, whose behavior is difficult to be predict.

> About the only problem I can see with an algorithmic technique is that users would have 3 aliases for the same mailbox, however any EAI aware app should be able to discover that the algorithmic ASC…

other problems with algorithmic technique can be found in the earlier EAI draft written by John. 

> Even if algorithmic alias generation wasn't a MUST or formal part of the spec, it'd be nice if there was a common algorithm providers MAY use if they think that approach is interesting.

As far as I know,  we can not find the automatci algorithm such as punycode which  can produce both the  user friendly and global unique address.
if there is a one, there will  be fine. unfortunately, there is none according to the current research.

Yao Jiankang

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