1. D. CrockerMail Addresses1 Structure and Scope of Internet Mail Addresses  = “@” = *( “.” )  “@” and “.” are global syntax  is global semantic  is globally opaque   Local to cited domain – local MTA(s) and local MUA(s)  No one else’s business!

2. D. CrockerMail Addresses2 Address Handling  Sender  Copy an opaque string  Senders do not construct addresses!  Source/Relay MTAs  Move message to  is opaque; ie., ignorant of local structure  Target Domain  Interpret  might follow local structuring conventions Multiple MX References  Distributed MTA  Must share syntax and semantics  Forward to master MTA  Same as “intermediate”

3. D. CrockerMail Addresses3 Conventions Conventions  Mailbox assignment  User vs. System chosen  Login-specific, or not  Structuring  Function of target MTA  May include MUA  Encoding  No global standards (well, almost none)  May be layers of encoding  May have significantly different presentation style

4. D. CrockerMail Addresses4 IEA Goals  Expand permitted range of characters  Global enhancement  Must not break installed base  Must not break local conventions(!)  Approach: Reserve “unused” bits  Outside current ASCII range, or  Special ASCII-based “framing”

5. D. CrockerMail Addresses5 Tidbits  Unicode representation vs. encoding  UTF-8 is merely one of several encodings  ACE is merely another encoding  strings are short  Intermediary MTAs do not interpret  Using non-ASCII bits changes this  Adoption times  New, endpoint-only protocol: 3+ years  Existing protocol: 10+ years  “transition” is forever  Existing multi-step infrastructure is worse

6. D. CrockerMail Addresses6 Enhancement Enhancement  Must respect local conventions  Without knowing them  Create Unicode segments  Flag start and flag end  IDN could rely on “.”, to flag end  IEA cannot  must define global segment end