Enabling Every User with a Unique Internet Culture ID
07 December 2016 - A Workshop on in Guadalajara,Mexico
>> MARK SVANCAREK: Okay, everybody, we're getting ready to start. Okay. Hello, everyone. Welcome to Workshop 144. We'll be discussing Enabling Every User with a Unique Internet Culture ID. We've received some feedback that the title is a little misleading, so this is, in part, about giving people internationalized email addresses that they can use as identifiers on the Internet. You went the wrong way.
As you can see, we're having some resolution problems on the screen, so ...
Thank you for your patience. So I'm Mark Svancarek. I'm from Microsoft. I'm one of the co-organizers of this event, and our agenda today is for the co-organizers to welcome you. We will have keynote presentations on various topics from various people. Then there will be an open discussion for 45 minutes to discuss various issues related to this topic.
So welcome to the event. I'd like to introduce Xiaodong Li, the CEO of CNNIC, whose dream it is to give everyone an internationalized email address and support internationalized domain names for everyone in China.
>> XIAODONG LI: Thank you, Mark. This is Xiaodong Li. I'm the CEO of CNNIC. It's my great honor to be here and to see so many different people here. At today's session, we've been having for many times in different topic. You know, since the first IGF meeting and also in the next couple of years, it has been discussed many, many times.
I think it's even that we need to work together to do a lot for the future development for the ID and also email address in different languages.
So just now -- I also joined the ICANN program update in last session. I'll also mention that the community needs to work together to solve the current problem to deploy the -- the ID and also the internationalized email address. We need to be aware there's a lot of -- I a lot of tremendous effort has been made and a lot of implementation and research efforts have been deployed, so, of course, this is also including panelists from the industry, from the email proprietors, so I hope in the future we have a very successful in this area.
If we want to recall memory from many years ago, since 1999, CNNIC and also myself have donated a lot of resources for the research of the Chinese domain name and also the Chinese email address. I think it's almost ten years ago I co-chaired the email address Internet working group to raise issues in the IGF to raise the international standard, also supported by many here, including John. I think it's a big effort from the community to do that, to solve the problem, but, you know, even nowadays a lot of issues with this.
Even there's some service -- email service providers support that, but because the country, the email address used to be -- has been used as the ID for so many systems, not only for email service, maybe so many people never use the -- this ID as the email service, but they will use the email address to be the ID, so that means that the unique ID is a very, very critical resource for so many systems, even for IBM, Microsoft, also some big companies, just like Alibaba in China, so if we want to improve that system, we face a lot of challenge how to support that.
So I think there's a lot of issues to be discussed, and also, as I mentioned just now, there's a lot of effort needs to be done in the future, so I hope that the committee members can work together, not only for the developers and entrepreneurs can work together to solve the problem.
I have best wishes for this session, hopefully it will be a success. Thank you.
>> MARK SVANCAREK: Thank you.
>> JIANKAN YAO: So, thank you Xiaodong Li. It's so nice that we were co-organizer with Microsoft and Mark. Microsoft is working with Mark with 23 years of experience in Microsoft, also is a UASG co-chair, so welcome, Mark.
>> MARK SVANCAREK: Thank you, Yao. As Yao mentioned, I am on the UASG, Universal Acceptance Steering Group. I've had a lot of roles in Microsoft, and currently one of them is to help engineering teams to evaluate new standards and opportunities based on these standards that we know have impact on customers and partners. IPv6 is one of those, EAI and IDN is another.
>> JIANKANG YAO: Thank you, Mark. Next we welcome Wanawit from ETDA. ETDA is one part of the organization. Welcome Wanawit.
>> WANAWIT AHKUPUTRA: Good morning, everybody. Wanawit Ahkuputra from ETDA, so I don't want to take that much time from you, and I think it's nice to be here, and thanks for the teams. We have the next billion that are not using a Roman corrector, so I do hope that this session we'll hear from feedback from you from the workshop. Thank you.
>> MARK SVANCAREK: Thank you, Wanawit. So here's our agenda, as mentioned. Andrew and John will present --
>> JIANKANG YAO: You want to -- slides.
>> MARK SVANCAREK: Pardon?
>> JIANKANG YAO: Slides.
>> MARK SVANCAREK: Pardon us. Please bear with us. So, for the agenda, John and Andrew will talk about their interests and concerns related to this topic, and then we'll have number of speakers, Microsoft, DotAsia, THNIC, and we'll cover other aspects of this. Will you drive off these slides or -- yeah. Okay. Good.
>> JOHN KLENSIN: Hi. For those of you who are lucky enough not to know me, I'm John Klensin. This is Andrew Sullivan to my right. We were originally asked to do separate presentations, and we decided it would be much more interesting to do an almost unprepared dialogue discussion between the two of us. These slides are an outline, which we may not follow.
The general idea is to try to share with you our perspectives, less on the specifics of implementations and protocols than on the issues associated with trying to deploy these addresses, and partly in the hope that people can keep their expectations enough in line with reality that it's actually possible to succeed rather than getting bogged down forever in things that are either not desirable or which won't work. Okay. Three buttons is forward, back, and stop?
>> MARK SVANCAREK: I think this is forward. It looks like forward to me. I think you have to point at the computer.
>> JOHN KLENSIN: Oh, okay. So our first issue when we started looking at this replicates that from the session description, as Mark sort of mentioned, it was very hard to figure out what we were talking about at this session, so I felt the first thing we should do is try to clarify that. I didn't know what cultural meant in this context and I didn't know what unique meant in this context, and I'm not sure I knew what a user was in this context, and other than that, we were in great shape. Why don't you feel to interrupt me at any point.
>> ANDREW SULLIVAN: I usually feel free to interrupt you at any point.
>> JOHN KLENSIN: Excuse me. When Andrew interrupts me, it is with my permission.
The other piece of these sort of fundamental issues we wanted to talk about was what trying to use an email address as identifier actually means. It's widely practiced. We'll talk a little more about that later, but it could be an impediment to actually getting nonASCII email addresses and even nonASCII domains deployed.
There's a second issue with email which is that -- Mark mentioned he had been -- Yao mentioned that Mark had been at Microsoft for 33 years -- 23 years. Okay. Well, I have been worried since about 1980 about the question of how to give normal human beings email addresses and let them communicate with each other, regardless of where they were.
And one of my concerns about this work is that we try to preserve that ability of anyone on the Internet who feels like doing so to communicate with anyone else on the Internet they feel like communicating with. And I'm very concerned that we not lose sight of that open communication goal in the process of giving ourselves email addresses and identifiers, whether they're the same thing or not, which are much more locally and culturally compatible.
So we're going to be talking a little bit about that too.
>> ANDREW SULLIVAN: So while you're going to the next slide, I think there are three themes I want to pick up here because they're individually important ones, and the first one is that there is a tendency with a number of these topics to fall into abstractions that don't always help, right, so you start with a fairly narrow problem and you think, oh, I've got this, like, identifier for domain names or for email addresses or something like that, and that's a fairly narrow problem, and then you realize that that thing has been reused for another purpose, like it's used for user identifiers in other systems, and then pretty quickly you're talking about, like, universal identifiers for people in the world.
And the problem is that the last of those -- the last of those problems is a -- you know, is a boil-the-ocean -- no, it's a boil all the oceans, maybe the ones on Jupiter also, right? Like, that's just too big a problem to solve, so one issue that we have here is that it's super critical when we're talking about these things to be concrete so that we can actually, you know, get a problem that is tractable.
The second one is that identifier reuse is great and it's a long tradition that we've got, but that's also the millstone that we've got to carry. The Internet is already deployed, so we don't have the opportunity to just start from nothing and say we're going to throw this all away and do something better, and some of the proposals that we sometimes hear from people sound very like, you know, we'll just build another Internet and deploy that and then everything will be great. Well, not going to happen.
And I think the third thing -- I think the two things are enough to get us started, so rather than blathering on, I'll let John go back.
>> JOHN KLENSIN: So I've said this already. When we looked at enabling every user -- okay. Well, we just may give up on this. No. It's -- two buttons is at least one too many for me. Okay. That's where I was trying to get to. My subtitle for this discussion is what are really the goals and what is the issue here. I was very certain the way I first read and other people read the subject name probably wasn't the goal and if it was, we were in trouble, for partially the reasons Andrew mentions.
-- mentions. So what we're hoping to do is we hope to get to the stage where we have an understanding of what the problem is and a closer proximation to and understanding of what the goals are, and -- and if we can't agree on that, we should at least be able to understand why we don't agree and where.
So I think we're talking about cultural in terms of script and language and other issues and not a whole series of broader but fairly important things, especially given some parts of the world. And similarly, with uniqueness, there's a question about whether we are talking about one identifier per user, which is probably not a good idea, and we'll talk more about that later, or an identifier which identifies only one user, which is a slightly easier problem but not necessarily one that can be globally solved. Similarly, when we talk about email addresses as identifiers, rather than things which we use to send and receive email, there are many, many systems that accept those email addresses and think that they're identifiers. You're coming shopping on my site, please give me your email address, you come back later, we want to look it up by email address. And we've got a long history, even in the Latin character world, the databases which have the nasty property which when an email address that went in is looked up, you don't find it because the email address, the lookup process looks different than the email address in the original entry process.
Internationalization doesn't create any of these problems, but it makes all of them worse or all -- or creates greater vulnerabilities to all of them, so, again, referring back to Andrew's comment about ocean boiling, having email addresses with local scripts matching people's names or whatever else they try to do is a far, far easier problem when those addresses are used for email than when they're used for general purpose identifiers of the Internet. It doesn't say you have to solve both problems because you may have to solve both problems, but if you define success only in terms of having a complete solution to both problems, if you're really lucky, it's 20 years off, and the other problem is one I sort of alluded to earlier, which is if we make our email addresses highly focused on the local language, local script, local culture, we then have a problem of thinking through what it continues to mean to communicate internationally.
So I think we may have talked about this enough, unless there's somebody who is frightened by it still, but if we're talking about unique cultural identifiers, people have a tendency to hear something else, and that notion of a possibly government assigned unique identifier by which everybody in the world can be identified is, I hope not -- not what -- not what anyone thinks we are talking about here.
>> ANDREW SULLIVAN: Okay. Let's move on.
>> JOHN KLENSIN: So the question becomes can we have identifiers that are reasonable to the culture, and the answer to that is yes, up to a point, and how far one wants to push that point turns into how hard you want to make the problem to solve. I had a micro conversation a couple of weeks ago that in Chinese there are a lot of characters which Unicode has made hard to use because they haven't been in common use for anything for centuries, but they still appear in some Chinese communities in names, and if you want those characters used in the names, because they use -- it's in your personal name, to be used in email addresses, then you have a more complicated problem than if you forbid that.
Now, is that important or not? I don't know, that's a cultural question. The only thing I can tell you as an outsider is that the problem gets harder if you decide to have to allow that. There are similar problems with other languages, old scripts, languages which have changed, orthography and eliminated characters over the centuries.
Again, if we can figure out a way to make this problem easier by constraining it, something about getting something done in the near future becomes a great deal easier.
>> ANDREW SULLIVAN: So I think this is an important point, and there's another way to slice it, but it's the same basic point.
There are three things in tension with one another here, and the first of them is we want people to have identifiers that are natural for them to use. If you want to enter something that you can remember easily and so on, you know, it should be like your name or it should be like, you know, something that is familiar to you.
The second thing is that we have to deal with people communicating with one another in a shared cultural context, so people who speak the same language or people who come from the same neighborhood or, you know, speak the same language or write in the same writing system, which is not necessarily the same thing as speaking the same language, right?
But then we've got this third problem, which is that we want systems to be internationalized, not localized; that is, this is the -- the distinction between having something that works for people in a particular community and something that works for everybody in every community, and depending on which one of those you want to make more important, you're going to have to make different choices about what to do because we can't have all of them all at once immediately, and I think that that is one of the big difficulties. It's unfortunate that we have this situation where we've deployed a bunch of stuff that gets in the way of these future things, but, you know, this is a classic example of that old cliche, making the perfect the enemy of the good, right? The question we have to ask ourselves is whether we want something that is at least usable for most people to get started, and I think that that -- that we sometimes skip over the distinction between those two possibilities.
Speaking personally, I will confess that, you know, because of my background, I always want to start with something and get something going before we get everything perfect because I would rather that, but there are people who then say in response to that, well, that's unfair to me because you've left me out, and I understand that problem, but I think that that is actually a difficult -- a difficult needs assessment problem that we have to face, and unfortunately, maybe we haven't done a good job of facing that needs assessment problem before we started fixing -- you know, working on the technologies, and so now we've got these nasty corner cases, and we've got three generations of them.
>> JOHN KLENSIN: And because of my personality, when Andrew starts charging down fixing the things that are easy to attack first, which is the strategy I agree with, I tend to start worrying whether the road he's following leads over a cliff and I try to map cliffs, and that's another piece of our problem here is if we make early decisions and deployments which are too simplistic and ignore other kinds of options, we may find ourselves in a situation where some language or some script cannot be accommodated in any reasonable way without tearing everything else down first and we don't want to do that. So again, this is a critical balance there, so I believe in moving forward and I think we also need to look ahead.
Okay. We've talked about the rest of this one. Oh, goody. Well, we're not going to get to the end of this. Okay. Skip this too.
Okay. No, not the last one that you skipped. So I want to make one more point about this notion of unique personal names. If you compare the name John Klensin to the name Andrew Sullivan, something very interesting emerges, or two things. The first one is that John C. Klensin and J.C. Klensin are unique and match John Klensin, but J. Klensin is not unique, and the other -- while John Klensin in any of those forms is unique on the Internet, there are probably a whole lot of Andrew Sullivan. And if you decide that these unique identifiers have to uniquely identify users in a way which feels good to them, we end up with solutions, like, Joe Smith 37254 and Joe Smith doesn't think 37254 is part of his name, for some reason.
And moving into multiple scripts doesn't change that problem for anybody who's -- the a national curl actuarial equivalent of John Smith, and it doesn't change anybody's national cultural equivalent of me, but I'm a unique case. Next slide.
>> ANDREW SULLIVAN: Just to make that slide worse, remember what we're trying to do is not to uniquely identify people just for email, but you're also -- because email addresses persist over time, you actually have to do this temporally, which means if Joe Smith 37254 was an identifier, it has to remain an identifier at least for the plausible lifetime of Joe Smith, otherwise it goes to the wrong person, so it's not just now this has to be a problem but over the course of generational time, which is kind of awful on the Internet given that we've got, what, two generations with time on the Internet so far.
>> JOHN KLENSIN: Okay. So we wanted to talk briefly about the difference between the IDN problem and the email address problem. The IDN issue is we've got a single global rigid matching system, it's deep hierarchy. When we started looking at internationalized domain names 15 or so years ago, we realized we had three basic choices about how to do that.
The first one involved changing the DNS to change its matching rules and how it understood strings, and we decided we couldn't do that because we said it would take forever if it could happen.
The second opportunity was to transfer all the labels what we call ASCII incompatible coding so these names could sneak by applications who didn't know about them, and that's, of course, what we decided to do.
And the third possibility was to adopt a two-step resolution model involving looking at user-facing identifiers which were a little bit fuzzy and could ask questions like, do you mean this one or that one? And then go to the DNS, which was network-facing, as it was originally designed, to actually look up objects.
The more we find people who are saying we need to change the DNS to do various things about bundling names, about fuzzy matching, about funny cross-tree things, the more it becomes possible that we made the wrong choice, that third choice might have been the right one, in spite of the fact it could have been deployed more quickly.
So I won't belabor this more. Good news, before we continue. First piece of good news is that neither email addresses nor domain names, nonASCII indicators are needed to communicate content, and content is almost clearly the most important part, so people need to think about what's important.
It doesn't make it less offensive for people to have to use names other than in their scripts, but it's worth remembering as we proceed. Next slide.
Okay. The email side of this is different and much more complicated because it is easier than the IDN side. We cannot map email addresses into some ASCII compatible form because we've done that already for other reasons, and anybody who has an implementation which does it, I will tell you right now, as a preview of the future, your implementation will not work in some important cases. You can't encode without breaking existing systems. The email rule, which is very important and which was discovered over and over again that when we violate email stops working is that only the target system can interpret what those addresses mean as a consequence, you cannot in general encase in code.
So IDNA situation, old applications continue to work with A labels. The affect is only ugly and culturally silly. It does work, and upgraded applications are just fine.
For email, the old applications simply do not work and sometimes don't work in very bad ways, and only the upgraded application comes send or receive or retrieve messages that have nonASCII addresses or nonASCII headers in them in either the sender or the receiver, and that's the issue people have to be clear about in this distinction in combining the two.
And we've talked about this. Try to use email addresses other than as addresses but as IDs. You may get yourself into problems. You certainly make the problem harder.
And we need to think about user expectations. If a user thinks that three different spellings of their name are the same, we've, at a minimum, got a tutorial problem, an educational problem if we really make it so they're not the same and we tell the email addresses are personal identifiers, and we'll bring this back up later if we need it.
And international interoperability may have different implications, depending on who you're talking with. The technical stuff, we've gone off and implemented this, is the really easy part. Getting to deal with the user expectations, getting it deployed, getting it to work comfortably, getting it to function across national boundaries is what's hard.
Coming back to Andrew's earlier comment, having an implementation which works well for people in one country and one language and one culture is a really important first step, but it's really only a first step.
And we're all impatient about this and we all want to move forward with it, and that's good stuff, but if you want to understand how fast this happens, think about how long it took us to get universal availability of plain text Latin character-only email. No international characters, no international content, no multimedia.
And the other question is to think about how long it's taken people to deal with reading and writing in languages they don't understand.
So we look forward to other people telling us how they've solved all these problems so that we can go home and stop worrying about them or at least telling us carefully what problems they're solving. Thanks very much.
>> MARK SVANCAREK: Thank you very much, guys. So now we've level set on some expectations. We've heard some of the difficulties and challenges ahead, and now I'd like to move to the next set of speakers.
>> JIANKANG YAO: You.
>> MARK SVANCAREK: Am I next?
>> JIANKANG YAO: Maybe use this.
>> MARK SVANCAREK: Okay. So I'm Mark from Microsoft, as I mentioned earlier. My presentation, I just have a few slides, is to talk about how Microsoft came to be interested in this topic and what steps we've taken to address it. And the focus here will be mostly on Office 365 but not really limited to that.
So our mission statement as a corporation is to empower every person in every organization on the planet to achieve more, and so right there that was an interesting way of thinking about EAI and IDN. You know, if you implement these standards, that's one more way that you can empower people to, you know, use their local writing method on the Internet.
So it was automatically interesting to us when we saw that there was interest in the topic again because it has been around for a long time.
I don't think you can read that, and really, you weren't meant to, but one of the first things we did was we evaluated what is the regional interest in these topics, who are the stakeholders in various areas, like New Zealand, China, India, Russia. Are there label generation rules panels that have been convened for the areas of interest, you know, to make it practical to create domain names and email addresses in those languages? Is it government? Is it UNESCO? Who's interested in those areas? And based on some of the information that's up here, we proceeded down the next step, you know, thinking, okay, there's some interest there, let's look at it again.
You can't look at that either. Another way of evaluating the value of this is to think of it as a change event within not just the ecosystem but within our customer and partner base, and so you can look at things as having various levels of impact from low to critical across different criteria, such as who is the customer segment, who is the audience, or how does this affect our brand, or is this global versus regional, are there regulatory compliance and legal requirements, and how would the adoption of this impact our market share, whether by us or by our competitors? And you can see the areas, which are circled, which you can't see, show our evaluation of where the situation was when we started and then the dash lines show that some of the areas were likely to become more critical over time, mainly because of government regulations.
So this further incented us to look at this, and so at this point we began to think, well, what would we offer relative to this because, you know, we are a software and services company, so at the end, it has to come down to very concrete sets of features, so consumer email is one of them, so thinking of Hotmail or Outlook.com, email for the masses, that's one possible scenario. It wasn't clear whether we could actually get a good return on investment on that in any short-term.
Commercial email service, which is provided to corporations, governments, and education, that seemed more likely and more likely to be impacted by regulations and compliance issues.
We are a Cloud services company, but we also have a long history doing on-premises infrastructure, you know. You have your own servers, your own directory services, things like that, and we have a hybrid offering, you know, where you have Office 365, but you also have servers on premise and they work together, so that seemed very likely as well because a lot of the customers who would be interested on the second bullet are tiptoeing into Cloud services, so they'd be interested in how to do something hybrid as well.
We see more and more people asking to bring their own domain name rather than saying I'm at Office365@myMicrosoft.blah, blah, blah. You just bring, you know, mydomain.com, and that's what your Office 365 tenant is named, and you would have email addresses at that same domain. And then finally, multiifactor authentication.
I don't know if any of you are forced to deal with multiifactor authentication very much, but depending on your situation, you may need to use an email address, a domain name, a password, a phone, a SIM, a biometric, some combination of those in that situation, internationalized email addresses would also be impacting.
So we decided -- and I think John is right about this. We decided to focus on concrete and short-term goals first, things that we knew that we could do readily, and we decided to focus on EAI, on email. We had already made lots of investments in IDNs, and we weren't concerned about our software services supporting them very well, we were much more concerned about EAI because we knew we hadn't implemented that end to end. Engineering teams had been doing opportunistic feature work for years but never committed to doing an end-to-end.
So the first thing we worked on was Outlook 2016, which is our desktop email client for Windows PCs, and that is now available. Based on that, we began to work on -- oh, and inactive directory as well. So no one uses those features as far as I can tell, but Active Directory has supported Unicode names for several generations. So with those -- pardon? So with those available, we could focus on Exchange Online, which is the Office 365 email service, which is built on the Exchange server. This is being deployed right now. In fact, if you have an Office 365 subscription, your mailbox is probably already enabled. I know there's a few percent of the mailboxes out there that are going to be in if the long tail, so I can't guarantee definitively that you're enabled right now, but the chances are very good.
And in progress, we have some of our other email clients, Outlook for Android, for iOS, and for Mac, and so we're hoping that this gets us most of the way through what I've been calling Phase 1. Phase 1 is being able to send and receive to and from EAI mailboxes. Phase 2 would be other scenarios, such as sharing files on Dropbox or OneDrive addressed to people with those addresses or using them more comprehensively as identifiers for various programs like, Bing Search Rewards, et cetera. That's Phase 2. We're not doing that right now. We're trying to close on Phase 1, and we're hoping that we can bring a little bit more critical mass so that people can say Gmail does it now, Microsoft can do it now, in addition to Coremail and XGenPlus, so maybe we can start looking at this and feeling like it has some chance of succeeding.
>> JIANKANG YAO: Next is Edmon. 30 minutes.
>> EDMON CHUNG: I will try. First of all, this is Edmon Chung from DotAsia, and thank you for inviting me to the panel. As I try to get my slide on, I guess -- I'm trying to, I guess, -- part of my presentation will try to move from a little bit more of the technical aspect that we talked about to a little bit more of the user expectation and perhaps the policy aspect of what we talk about here. Instead of using the clicker, I guess I'll say next slide. So next slide. So here's really just graphically, you know, letting people know -- I think the previous three speakers have already touched on that. Email addresses are not only used to send email these days, whether it's Facebook account registration or your, you know -- many of the different social medias or any account creation utilizes an email address, and that's where some of the issues are created, and that's where it's important.
And as one of the anecdotal examples and why it's important on a policy level, there was an anecdotal example that when somebody was trying to register for their vote in the U.S. elections, they were unable to because the U.S. government system didn't allow certain email addresses that have a new top-level domain or are utilizing different languages. I don't know whether that affected the results of the U.S. elections, but that is besides the point.
The point is it has policy implications on, you know, how government conduct their businesses online with these identifiers. Next slide, please.
And it is also -- some of the other areas of -- one more click. Some of the other areas that you find problems with introducing these new characters into email addresses are, like, other types of email filters or spam filters, for example, is a good example. When spam filters see that, hey, this address looks a little bit weird, they cut you out, and that has implications on the developing world where a big topic here is getting the next billion online, and more often than not, their language -- the native language is not English, and if they utilize an email address with their own native language and it's blocked by spam filters, then that presents another type of challenge. You know, that's really -- you know, in terms of policy aspect, those are the issues that we talk about. Next slide, please.
And that's where universal acceptance and the Universal Acceptance Steering Group is trying to work on, and Andrew mentioned about perfect being the enemy of good. This is also how we conduct our business, looking at what the, I guess, low-hanging fruits and also where we can hit the critical mass because to have all the systems everywhere on the Internet to be available to accept all the email addresses and all the top-level domains is probably impossible for the foreseeable future, but we need to get to a critical mass so these can be used. A lot of Internet standards are not the perfect sense in universality, and that's how Internet evolves. We get to the critical mass, we get to a point, but that requires -- and that requires your attention in terms of the -- on the user end and also on the policy end. Next slide, please.
And in terms of the UASG, the Universal Acceptance Steering Group, we've -- one of the things that in the last couple of years we've identified a kind of a standard to think about these issues and to define it, both on the IDNs and now on the email address internationalization, how we accept, validate, store, process, and display these identifiers, and these are aspects that you need to look at in terms of your system, whether it's a government system or corporate system, how to deal with these identifiers coming in. Next slide, please.
And in terms of our progress, the current -- oh, one -- before that. That's the exciting slide.
So -- keep going. So the current projects on EAI, in fact, we're excited to see that there's a growing participation, so -- and if you're still interested to participate, look for UASG, Universal Acceptance Steering Group on the ICANN website, and it's an open mailing list, just send an email in to join.
I'm guessing it does not support EAI just yet, so please use an ASCII email address. Unfortunately -- there are a number of guides that we're working on, and please do participate. Next slide.
But we go back to a question, do people actually use it, you know. A lot of people will say but nobody uses these names. I guess it's also a matter of a chicken-and-egg problem, but one of the things I'm excited about -- next slide -- is actually things are going to change.
Today, maybe typing an email address in your own native language is a challenge, one more click, but think about the audio input with your mobile phone, that's going to change a lot. That's going to change a lot of things, and we know how mobile Internet is going to change. It's hard to imagine Chinese users or Arabic users speaking English to their phone and trying to send an email to somebody else, and that's when email address internationalization or IDNs is going to really matter and it's going to make a difference, and that's why bringing on the next billion is going to be important. Next slide, please.
And this -- and the other thing that is coming along -- next click -- Internet of Things, again, speaking to your fridge, highly unlikely you'll use English rather than your native language, and this is a slide I've shown for many years, and he's is saying I should have some progress. Next slide is the progress. It is possible to use domain names for Internet of Things. Next slide, please, because I'm running out of time.
The next important aspect is sustainable development goals. This has relationship to sustainable development goals. Next slide, please. And especially in infrastructure development. If you -- I won't go through in details, but eight, nine, 11, 12, they all include aspects of how -- how infrastructure is developed with the local -- localization and the local community in consideration, and EAI and IDNs are all part of that, because if you think about the Internet, we often think about it as an international tool, but it's as important in the local condition, you know, local company talking to your local audience, that's where EAI and IDN is going to play a role. Next slide, please.
And that also has an aspect of the cultural aspect and heritage aspect of the SDGs, so 4, 6, 8, 11, 12, 13, 15 all talks about the cultural aspects. I'll jump to the last slide.
And that's why IG is involved, and in education, that's what we're trying to do, and IG, which is our tiger, is also focused on sustainable development, off course happening tigers but also universal acceptance. I won't talk about this, but you can come to our booth and I will explain why SDGs and universal acceptance are actually, you know, a very important part of it, because of the enabling of the local community in terms of infrastructure development and also in terms of heritage protection, protecting, you know -- and also thriving language and cultural aspects for the Internet, so thank you.
>> JIANKANG YAO: Okay. Thank you.
Next is Marvin.
>> MARK SVANCAREK: You can drive it.
>> MARVIN WOO: Good afternoon, everyone. This is Marvin Woo from Coremail China, and Coremail is the first EAI provider, and today, I will, as a provider, just show some experience of EAI.
I use my EAI account for work every day, almost one year, so I feel something --
In 2012 Coremail is the first EAI provider, so we found some difficulties. For example, no client to support EAI, and they ask me if I want to have an EAI account, which -- so we do something -- next. So now Coremail release some client iOS engine and Windows, like mobile clientele and PC clientele. I use these clientele work every day, almost one year I use my EAI account, and I use my English email address. I only use my EAI address to send email, you know. Next.
And we released EAI platform and we gauge EAI account like this, and now we gauge more than 100,000 users. Next.
And this is some commercial example. In China we have enterprise custom, and then we an EAI system for custom, and so we -- this is the first real way to catch many through our custom. Okay.
Now I have some challenges, and the first is EAI is limited in the local cycle. For example, my father, he doesn't like EAI account because he can't understand English, but for my foreign friends, like Mark, you can't understand my Chinese email. It's fairly terrible for you, so EAI account is using a no code cycle, I think. No, no, no.
Another challenge is few applicants to accept EAI account as latest ID, so it's an endless loop. No application can accept EAI email address, so no people like to use. And software provider have no interest to improve their system, and still people use -- few people use EAI account. It's an endless loop, at least in my field.
Like Apple, Google, Microsoft, and also the -- as email address, as register ID, so it's really an ID, but they can't accept EAI account. If I use Chinese -- another EAI email address through latest, it can accept, so the earlier ID I can't use to -- our Internet education.
The last part is I think maybe in the future we can use email address in the local cycle or a user like to use EAI but in different country or different language they can't use it, so I think a code is necessary maybe for a long time because -- so maybe several millions of surveys for enterprise build itself, so they can't upgrade a system, so I think maybe Punycode is necessary for a long time in the future.
>> JIANKANG YAO: Last thoughts. 30 seconds.
>> MARVIN WOO: Okay. Okay. This is common to something like Microsoft Exchange Online where it released our Coremail SaaS and custom. Also, all of them can support EAI. Okay. That's all.
>> JIANKANG YAO: Great. Thank you.
>> MARK SVANCAREK: Thanks, Marvin. Next up we have Pensri from ETDA.
>> PENSRI ARUNWATANAMONGKOL: THNIC.
>> MARK SVANCAREK: THNIC. I think you have a file compatibility problem.
>> PENSRI ARUNWATANAMONGKOL: PDF you can't open.
>> MARK SVANCAREK: We can't display her presentation right now, so she'll just have to speak to it.
>> JOHN KLENSIN: So we can open proprietary but not PDF.
>> PENSRI ARUNWATANAMONGKOL: I'm Pensri Arunwatanamongkol from THNIC. Our aim is to build millions of Thai Internet to those not familiar with English character, they cannot recognize, they cannot write, so I think the IDN and EAI is necessary for them.
So we start our journey in 2011 where we provide Thai IDN. At that time, EAI was started with help, and from 2014 until now, we join many activities and did many tests. Finally in June this year we started to offer the Thai EAI service and Dot Thai domain name for the Dot Thai domain name using costs for platform, and we plan to provide free EAI email account to people next year, so they can have the email.
So today actually I would like to share my experience in implementing EAI, but we cannot see that one. We can show later.
So we list problems that we face. Like, the first one is delivery label. That means to deliver email address that is using EAI to the server that do not support EAI. We need solutions, so they provide ASCII and nonASCII account -- address and point to the same email mailbox to solve this one, and they are, like -- the system is SMTP available.
Next we found is that the interoperability, as different systems might use different encoding, so to -- we found out a message displays incorrectly, as that -- and that leads to incorrect address when the server tries to reply. To solve this issue, they placed the content type and encoding at the top of the header.
Next interoperability issue is data from compatibility, so we can have like UTFA -- @UTFA or can you have other type, like -- you need to show that. Okay.
So they will be able to display all of them and then convert them to Unicode before sending back. As we talk about interoperability, we need to work on each email system one by one, so -- or case-by-case basis. It would be helpful if we can have, like, the best practice so that all of us can follow and maybe go by scale of interoperability opportunities is also needed.
Next issue is that there is no client application now that can do POP and iMap for Unicode account. Microsoft said that Outlook 2016 can do that, right?
>> MARK SVANCAREK: I thought so, yeah. Did your tests show otherwise?
>> PENSRI ARUNWATANAMONGKOL: Maybe we need to work out interoperability.
>> MARK SVANCAREK: Bugs are always welcome.
>> PENSRI ARUNWATANAMONGKOL: Right. So currently only webmail can do, and to inform us that they will develop a client application for our users. Yeah.
And to provide EAI address for our users, we also want service provider that they can receive and reply back to all, so -- our user, so we build up a Wiki page to tell the small email service provider there's a guideline to set up that EAI by turning on the EAI if they are using -- so as many of you said, we need, like, big player, like Google, Microsoft, Yahoo, Apple to support -- fully support EAI so that the ecosystem can happen, so the last -- last -- actually, I would touch the same, like, UA lady, asset plan lady. That user can use that EAI to register for, like, Facebook, Twitter, banks, or even government services.
So we would need to list them, so we -- I think they are doing that one. Okay. So that is my presentation.
>> MARK SVANCAREK: So, thanks, Pensri. Her presentation actually has a lot of great diagrams in it to show what they're doing and how they're implementing it, so let us know if you would like to see that afterwards.
So that's the end of our prepared speakers, and now we'd like to have an open discussion and we'd like to maybe break into groups to talk about things like real-world deployment experiences, what we've learned, challenges and issues that remain, how we can enable every user with an Internet ID, a discussion of whether or not email addresses are good Internet IDs or not. I think that will be enough for now, so -- yeah, I don't know. Should we divide into --
>> ANDREW SULLIVAN: You're the moderator.
>> MARK SVANCAREK: So perhaps we could -- question. Are there some questions?
>> AUDIENCE MEMBER: Yes, it's a question, and maybe a set of comments as well, because I'm still grappling to get onboard with your premises that an email address can be used as an identifier. Because there are -- I mean, it's counter-intuitive. We have a lot of places where we need to provide -- when we provide -- even email address providers ask for other factors for authentication, to factor -- two-factor authentication, especially for numbers, because phones are very individual, and they know when they send the codes, you'll be the one receiving it, and it's kind of more reliable in practice because people use phones for a lot of things every day, et cetera, but we have a lot of issues, spam and -- I mean, many people have my email address that I never met, and they send me junk email and all that, so anyone who has my email address can pretend to be me, if you use an email address as an identifier. That's a problem, and note that even government-issued identify is not just a name that's an identifier, it's a triangulation of many different data, it's the name and date of birth and gender and those sorts of things, so it's a triangulation of those data points that makes it more likely that the credential represents uniquely an individual, so I still don't understand how you use an email address as an identifier, especially that you didn't mention any other factors.
If you had in mind a password, the problem is passwords are things that are very annoying and very -- I mean, they're not manageable on the long run, and a lot of people in the technical world are thinking about how to get rid of passwords, so you have a lot of identity technologies being developed. The latest one I heard of is the Distributed technology, like Block Chain and stuff like that, so for me to hear that email addresses will be used as identifier is like going backwards, so can you explain that?
>> MARK SVANCAREK: Thank you for your feedback. I think Andrew would like to answer first.
>> ANDREW SULLIVAN: Thank you. So this is exactly in line with, I think, some of the remarks that John was making at the beginning; that is, what you have to do -- before you start saying here is a thing that we're going to use as an identifier is that you have to ask, so what is this an identifier for, what is the purpose to which you're going to put this piece of identity information and what consequences follow from that? And so if -- if I'm going to use my email address as an identifier, say, to Twitter, you know, so that I can also generate, then, a Twitter handle from that so that people can identify me within the Twitter system, that has certain implications, like, for instance, that people can, you know, tweet things to me, but it's rather less important, really, I think, that people be able to get their tweet information to me than, for instance, that my tax return be identified and associated with me because one of those things sends me to jail if I do it wrong and the other one doesn't, and so those kinds of things are among the questions that we have to ask.
And I think what John was saying at the beginning of this was the initial scope seemed to be this enormous problem of, like, unique identifiers for individuals, and then it turned out actually that the scope of this is enabling people with an identifier that they can use when they go out into the world to identify themselves consistently across systems and building on top of the EAI system.
That is a very different problem, and I think that you're right to ask whether these two things are the same thing because I don't believe they are. And more importantly, there is the follow-on question of whether we actually want people to have a singular unique identifier that carries across all of the systems. Personally, I would say that that is very close to the worst idea I've heard all week, so I think that that's a really bad idea, but, you know, I mean, people could have a discussion about that, but I think that what we tried to do at the beginning of the session was narrow the scope so we weren't also tackling that problem because I think it would be a very different discussion we'd be having.
>> JOHN KLENSIN: Yeah, just a quick one. I hate the idea of using email addresses as identifiers for all of the reasons you mentioned and several more. Our difficulty is that it has become an extremely popular habit in a very large portion of the world, good reasons or bad reasons, whether we can get people to back away from that habit or not is an open question. We need to understand better as we move into this new phase of identifiers or of email addresses, just how far we want to go in that direction and what the implications are.
I would even disagree with something Andrew said, which is that one could have a perfectly good email address without implying that it's an identifier at all, and maybe that's an option we should be pursuing, but, again, my main argument is we should be thinking about these things.
One additional thing for everybody, I am going to make a personal plea, get the term "EAI" out of your vocabulary before it causes far more confusion with all of the other three-letter magical acronyms floating around. Talk about it as internationalized email if you want to, use the correct technical term which is SMTP, but it's merely a working group which we picked after we were angry because all the other names had been taken and we were trying to keep it short. Let's try not to use that as a terminology generally in talking with each other and especially with talking with other people because we will just create confusion.
>> MARK SVANCAREK: I think it explains why it's EAI and not IEA.
>> JOHN KLENSIN: And if you know what an IEA is, you probably know why. Edmon.
>> EDMON CHUNG: I guess that's part of the identifier problem, right? So in response, the way I see it actually, email address is one type of identifier. It doesn't have to be the only identifier. You have, like, in your physical world, you have your passport number, you have your license number, you have your physical postal address, you have your phone number. I guess one of the key aspects that at least I want to talk about and I think the group wants to talk about is think about your phone number. In my place in Hong Kong, in my lifetime, we've moved from six-letter -- six digits to seven digits to eight digits now. We're talking about databases that is only able to accept phone numbers in six digits and choke on seven or eight digits. Here is a case where systems use email addresses, whether they are as identifiers or not, but they -- you know, now that we've introduced other languages or other characters into email addresses, those databases now start having problems, so I think that is a bigger problem that we need to think about and address.
Whether it becomes the only identifier, I don't necessarily think that's the pertinent kind of question we're asking, but -- and back to it is already being used as a kind of identifier, so let's make sure that, you know, the identifiers -- the systems can use the new types of email addresses, which includes native characters, and that's, I think, an important aspect.
>> AUDIENCE MEMBER: Just to clarify, I wasn't assuming that you wanted to be the unique identifier for anything. Even my name in some contents is an identifier. In my family I'm the only one called Mawaki, so it's an identifier, right, but the question is for what it's worth, what are we going to do with it? Why taking it from the status of being just email address to an identifier status, for what? That's the underlying question.
>> MARK SVANCAREK: Okay. So we have Wanawit and the gentleman there and then Xiaodong.
>> WANAWIT AHKUPUTRA: Yes. I would like to point out one other key aspect that's been overlooked. The email is part of the credential that requires to use in the signatures in the world. We have 137 trade agreements in the Pacific alone, 37. There are 27 measures talked in the trade agreement. 50% of them talked about the major delay to the eSignatures. What are we going to do? What are community going to give the answer? Government have to issue the paper? Email identifier is only means to be used, and I don't know whose fault this is, but that is the expectations from the world that we're living with. People do not know what is the problems there. I'm not talking about the identifier used across the system, but even within system, like people we don't use the Latin correctors. None of the government offices are carrying the official Latin names, so how do you know if this is the qualifier or his credential could be able to sign this document and send across border, and I think what I'm talking here is not about the open identity or using, but it's there as part of the credential needed to provide to authenticate the trade documents. And the baseline is there, the trade facilitation agreement already reached 100 countries, eight countries to go. We expect next year we'll close. We have one year. 147 countries. If you look into the list, 80% of them are not using the Latin. This is the -- the problem is far more bigger than what we're talking here.
It's not talking about this kind of messaging system. What IGF gives to us is a nonfragmented architectures of electronic mails or whatever you like to call SMTP. Without doing this, we'll get into the fragmented of the web applications that none of the governments will accept who's going to be the primary government. Email is the only means that can maintain the collaboration works, exchanging document. If we don't do anything, I don't know how the world's going to lead to? Maybe they will also need to have an English name within next three years, and I don't know -- I don't have the solutions, but I think you talk about chicken-and-egg problem, that's a paper published. The measure I've been talking about is these eSignatures, and I believe what you like to call EAI or email, it's a basic credential how we communicate. Thank you.
>> MARK SVANCAREK: Thank you, Wanawit. The closer gentlemen.
>> AUDIENCE MEMBER: So I put my hand up a few minutes ago because I thought Andrew was seriously overthinking the problem, and I think two other people who have spoken since I put my hand up initially have actually identified this a little bit better than I could have, so I'm going to draw on their words.
The first is people don't actually want to use email identifiers, they want to use email as a return routability check, so it's an extremely basic form of proof of possession. You claimed X and I can actually send you a piece of message that you can use, some piece of text to say I've got it, therefore, we've established some return routability check, and it's a bootstrapping mechanism for far more complicated things, and as Edmon pointed out, lots of systems abandoned email as boot strapping system and have gone into boot strapping based on telephones. WhatsApp has built up a million users without using your email address because they have a different bootstrapping mechanism involved, so I think one of the questions that reads on the gentleman's point here about what are we going to do is one question we can ask ourselves isn't so much can we deal with the -- the tension of the fact that, you know, email has already been deployed for 30 years and changing it is very painful, with -- China has been deployed a good bit longer and changing it is equally painful or even more so, by saying are there fairly simple bootstrapping mechanisms which are out there which may serve a similar purpose to get us to an identifier that is, in fact, useful for some of these use cases like digital identity?
But I don't think it's really practical for us to look at this and say we are going to abandon this problem because, as has been pointed out here, at the moment the email system does not provide an effective return routability check for a very large part of the world because they can't create email addresses that make sense in their environment, they can't get them delivered by many of the systems that haven't been upgraded, so it doesn't work for this. Maybe it's not the right answer for this. Maybe we just say, hey, if what you're looking for is a return routability check, you need something that is, in fact, a simpler mechanism than that, and maybe it is based on E164 numbers or something that doesn't have the same internationalization consequences of a text string, but leaving these people out of the world we're creating because of backwards compatibility with one particular mechanism is hopefully going to push them into other mechanisms people adopt or hopefully push us to create ones that work.
>> MARK SVANCAREK: Thank you.
>> AUDIENCE MEMBER: Whatever you lack, the email address -- I mean, the email address, the user has to choose the email address to be the identifier for so many applications on the Internet service, so I -- because the email is not only email, it's very good profile, which is a combination of a person's name or identifier, institution name, and also maybe includes the country name, so that is a natural way to identify one person in the real world.
So they cannot change the requirements of the people, they want to use some kind of culture name to identify themselves.
Maybe it's an email address, maybe it's another thing, something else. We need a combination to identify ourselves is my comment.
>> MARK SVANCAREK: Thank you.
>> AUDIENCE MEMBER: Thanks. Just very quickly because one of our questions at the beginning was around what other sort of possible means and mechanisms could we investigate to -- I come from the global mobile industry session. I just wanted to add that we have actually a couple of digital initiatives that are based on the premise that individuals can use their phone number as a means of authentication and accessing services. Now, clearly, we're not saying this is the only means available, but depending on the use case, the mobile number could be one option, so there are different levels of assurance, authentication, so accessing Twitter versus accessing a bank account would require different levels of assurance, but we believe that mobile operators are in a good position to be able to leverage on existing assets to authenticate a user against a third-party service, and, you know, we invite at least in this session to speak to us and anyone about our initiatives, but we certainly believe that mobile numbers can act as identity sort of credential to accessing third-party services. Thank you.
>> MARK SVANCAREK: Yeah, we do agree that there's multiple forms of identity that could be prepared. I think back to the keynote at ICANN 57 a few weeks ago where they were disc