What Chairing ICANN's Universal Acceptance Steering Group Taught Me

I was building mail servers before I was writing policy

I did not come to ICANN's Universal Acceptance Steering Group as a policy person. I came to it as someone who had personally designed the protocol-level architecture behind XgenPlus, the IMAP, SMTP, POP, anti-spam, and webmail layers that our mail platform still runs on today. By the time DataMail launched in 2016 offering email addresses in eight Indian languages, one of the first services of its kind, I already understood, from the inside, exactly where the internet's promise of "any language, any script" quietly broke down. It broke down almost everywhere. A domain name in Devanagari would resolve. The email address built on top of it would bounce, get silently dropped, or get rejected by a form field somewhere three systems downstream that assumed every address was ASCII. That gap between what the internet's standards allowed and what software actually accepted, that gap has a name: Universal Acceptance. From 2019 to 2023 I chaired the global body responsible for closing it, the first Asian elected to that role.

I mention the engineering background first because it matters to what follows. Most people who end up chairing a standards body arrive as diplomats or policy specialists. I arrived as someone who had shipped the software the standard was supposed to fix, and who would go back to shipping more of it the moment the meeting ended. That gave me a different vantage point on the job, and it's the reason the lessons below are less about ICANN process and more about what it takes to get very different people to agree on something real.

The hard part was never the character encoding

If you described Universal Acceptance to an engineer in one sentence, it would sound almost trivial: make sure domain names and email addresses that use non-ASCII scripts, Devanagari, Bengali, Sinhala, Arabic, Cyrillic, whatever, actually work everywhere they're typed, not just in the systems that happen to expect them. Trivial, until you try to get the parties who would need to change their software to actually change it. Browsers, mail clients, government portals, banking systems, and e-commerce checkouts all had their own reasons, mostly inertia, for treating anything outside the Latin alphabet as an edge case rather than a requirement. Nobody was against Universal Acceptance in principle. Getting it prioritized in practice, across organizations with no shared incentive to move first, is a completely different kind of hard than getting a compiler to accept a new character set.

That's the lesson that has stayed with me the longest: the technical spec is rarely the bottleneck. The bottleneck is getting a room full of people who don't share a native alphabet, a regulatory regime, or a commercial incentive to agree that a problem is worth fixing together, and then to actually go fix it in their own codebases on their own timelines. Chairing that process for four years taught me that consensus across genuinely different stakeholders isn't built by having the better argument. It's built by staying in the room long enough, and specific enough about what "done" looks like, that people stop treating the standard as someone else's problem.

Four countries, one script family, and no room for assuming your own defaults

Alongside chairing UASG, I co-chaired the Neo-Brahmi Generation Panel, the group that built the multilingual domain-name standard for India, Nepal, Bangladesh, and Sri Lanka. Neo-Brahmi scripts share a common ancestry, but that shared ancestry is exactly what makes the standards work harder, not easier. Scripts that look related to an outsider often have subtly different rules for how characters combine, which visual variants are equivalent, and which combinations could be abused to spoof a domain that looks like another one. You cannot write a single domain-name policy across four countries by assuming your own language's conventions generalize. Every assumption has to be checked against scripts and administrative contexts you don't personally use day to day, with people who have every reason to insist their language's edge cases get accounted for rather than smoothed over for convenience.

What that work made concrete for me, in a way chairing UASG at the global level sometimes kept abstract, is that "multilingual" is not a feature you bolt on once and reuse everywhere. It's a discipline of continually asking whose default you're assuming, and building the panel's decisions so that no single country's script conventions quietly became the template everyone else had to bend around. That is a harder and slower way to build a standard. It is also the only way to build one that four different countries will actually adopt rather than tolerate.

I run the company differently because of that chair

The most direct translation from that standards work back into how we build software at Data shows up in two places. First, we audit for Universal Acceptance and internationalized addressing as a baseline requirement, not an afterthought, in our own products. See RajMail, the multilingual government email platform we built on that same engineering foundation, independently documented in ICANN UASG's own February 2019 case study on its adoption. That case study exists because we treated the standard as something to build against from day one, not something to retrofit once a citizen complained their name didn't render correctly in an email address.

Second, and this is the part I didn't expect the chair to teach me: I run consensus-building inside the company the same way I ran it at UASG. When two teams disagree about an architecture decision, the instinct is to find the technically correct answer and hand it down. That works less often than people think, for the same reason it doesn't work across countries with different scripts: the disagreement is rarely really about the technology. It's about whose assumptions get to be the default. The discipline I picked up chairing a global standards body, stay in the room, name what "done" actually means, and don't let the loudest stakeholder's convenience quietly become everyone else's constraint, is the same discipline I now expect from anyone running a technical decision at Data. It is slower than dictating an answer. It also produces decisions that survive contact with the next four teams who have to live with them.

I still think about that gap I noticed years before UASG existed, a domain name resolving while the email address built on top of it silently failed. Four years chairing the body responsible for closing that gap taught me that the gap was never really about character encoding. It was about who gets to assume they're the default case, and who has to keep proving they belong on the internet too. That's a lesson that outlasts any one standard. You can read more about that standards-body work, and the engineering credential underneath it, on my founder page.