Algorithmic Downgrade
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
Algorithmic Downgrade
by Shawn Steele
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
_______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
