WEBVTT 00:00.000 --> 00:16.240 Short version is it's going better. We can take a break. Still some work to do. I'm required 00:16.240 --> 00:23.720 to talk about myself first and then about my employer. My work involves me fixing bugs, 00:23.720 --> 00:31.160 talking like this, doing technical support, lots of things. I do it because I really care 00:31.160 --> 00:38.840 about the email and about having one internet come into the entire world. I think that's 00:38.840 --> 00:48.360 an important goal for society. Some of the work I do I do really because the Chinese should 00:48.360 --> 00:57.000 not have their own internet world up from the rest of us. I used to be a Linux person 00:57.000 --> 01:10.040 back when that was really rare. It's really hardening to see how what was a rare back in 1992 01:10.120 --> 01:18.520 when I first installed Linux has become totally come in place. Linux devices everywhere 01:18.520 --> 01:27.720 I live everywhere I stay. Right, I work for ICANN, which is the organization that manages 01:27.720 --> 01:37.880 the DNS roots, but also a lot more. When you send packets, those packets are rooted to ISPs. 01:37.960 --> 01:46.200 Those ISPs have numbers. We assign those if we were to make a small mistake, some part of 01:46.200 --> 01:55.000 the net would break. Basically, it's a set of databases that have to be up all the time 100%. 01:57.080 --> 02:02.280 There are ones that matter actually have been up 100% for 20, 30 years now. 02:02.360 --> 02:17.000 No downtime at all. Perhaps I shouldn't say so, but a colleague of mine complained last year 02:17.880 --> 02:24.200 that she was one of only two people able to do some critical work and the other one was on an 02:24.280 --> 02:35.080 airplane. She got pulled out of beds to type something. In one sense, it's boring, it's 02:35.080 --> 02:41.240 getting countries to agree that the web should be one, that our routing should be one, 02:41.240 --> 02:48.520 our DNS should be one. In another sense, it's incredibly technical and exciting for people 02:48.520 --> 02:59.000 like me. Enough. I've done my duty. What I work with is unicoid addresses in email and to 02:59.000 --> 03:08.760 some degree in the DNS. Actually, yes, addresses in the DNS. This is an example of one. 03:10.920 --> 03:17.480 You can see that there's a unicoid string, non-asky string in the domain there. You can see that 03:18.040 --> 03:29.880 just plain UTF8 in the subject and in the body. There's no encoding of anything and there are 03:29.880 --> 03:38.840 two syntax errors in that message, not three. So the question is, can any of you spot the errors? 03:48.200 --> 03:57.880 Right. The domain should have been puny codes. Wrong. You can do it like this, 03:57.880 --> 04:07.400 assuming that the software supports LFC 6531 and later, which was not the case 10 years ago 04:08.440 --> 04:13.800 beginning to be majority now. The code had been supported that last week. 04:14.760 --> 04:20.360 The syntax errors are the missing from field required and the missing date. 04:24.280 --> 04:28.520 I would say that the features are that there's no mine encoding anywhere. 04:29.400 --> 04:34.840 The only thing that you need to do with the modern style is to specify the content type that the 04:34.840 --> 04:43.960 character set is UTF8. Not all software supports this, but since Gmail supports it, 04:43.960 --> 04:56.200 who cares about the rest, right? I actually have presented on this and someone in the audience wanted 04:56.200 --> 05:02.200 to test it and it turned out that every person in the audience used either Office 365 or Gmail. 05:02.200 --> 05:10.440 Not sure what to say about that, but it saved me on that day because everyone was able to use it. 05:13.720 --> 05:18.280 I'd like to have some more support. This is Gmail, the screenshot, yes, that is C. 05:19.080 --> 05:29.800 It's the message from data mail. How many of you know about DoveCotes, K9 mail? 05:31.800 --> 05:38.440 Amarvis, I think. DoveCotes and data mail is a company that forks things like that and then sells it to 05:41.640 --> 05:47.480 the biggest customer is the state of Rajasthan and there are big Indian customers. 05:48.280 --> 05:57.560 In order to get nice Indian addresses, I am required to hide them in a little bit, but what you say 05:57.560 --> 06:06.600 here is a top level domain. DoveBarat, the Hindi word for India. India as a country has 06:08.520 --> 06:17.560 15 top level domains, one for each of the alphabet that are in common use there, official languages. 06:19.000 --> 06:28.440 They have 15 because they have fairly large economy and some people speaking English and some people don't. 06:30.280 --> 06:39.000 It's a society where it's perfectly possible to be a lawyer, for example, and pretty much not deal with English. 06:39.560 --> 06:53.560 In my past existence, I was a contractor at an accountant. The accountant might work entirely 06:53.560 --> 07:05.000 in Bangladesh if that was in co-cutter. This is meant to give people the choice. 07:05.880 --> 07:12.280 The people who want to use English, find the one, people who want to use Malayalam, 07:12.280 --> 07:17.160 Bangladesh, Hindi, can use that, their choice, not push by the computers. 07:26.680 --> 07:33.800 This time I wanted to talk more about higher level stuff. I took, I removed the parts where I speak 07:34.040 --> 07:45.560 S&TP. S&TP is simply to just send you debates. We're getting to the point now where open source 07:45.560 --> 07:56.280 has quite a lot of support. The four open source IMF service that I have on the top there, 07:57.160 --> 08:07.480 account for something like 90% of deployments. Cyrus is most of the remaining 10%. They all have 08:07.480 --> 08:15.400 support rates, which is great for test days. It means that if you have an email client, 08:17.640 --> 08:20.760 it has become much simpler to test that this works. 08:20.760 --> 08:31.240 You also need S&TP service of course. Again, the majority have support now. It wasn't like that 08:31.240 --> 08:40.600 five years ago becoming okay. Does anyone here like to write code in JavaScript? 08:41.560 --> 08:51.000 Okay, well, minority. I'll not talk about that then, but it does exist. Email engine is under 08:51.000 --> 08:59.560 say? Okay, excellent. Very nice work. It was a joy to test email engine.app. That's him. 08:59.560 --> 09:17.560 Do I? Well, I'm everyone's friends, so I can say more than humans. That SQ male and the other 09:17.560 --> 09:24.600 fork. I guess the SQ male people don't agree with the other four people about what 09:24.600 --> 09:33.400 more than humans is, but they both have support rates. So fine. There are a couple of 09:33.400 --> 09:45.560 do we clients today? Excellent. There are a couple more. If you go to China, then Michael's big 09:45.560 --> 09:51.240 competitor, a company called Core Mail, has a 50% of market and a fine client. 09:51.560 --> 10:03.320 All this means that testing is simple. Oh, by the way, I need to say that. These are not 10:03.320 --> 10:09.720 complete lists because it would be forbidden for me to make any sort of complete list. I can give 10:09.720 --> 10:19.720 examples, but my boss beats me if I'm making complete lists. Also, since everyone uses libraries 10:19.800 --> 10:28.120 these things, including email engine, which uses nodes. I've done some work on this. All the 10:28.120 --> 10:37.240 people have done more. Most languages these days have a built in library or a common library. 10:39.400 --> 10:46.520 In JavaScript, no, there's not built in, but everyone uses no right. 10:46.600 --> 10:57.400 In Go, there's something built into everyone uses immersion, PHP, everyone uses symphony. All of 10:57.400 --> 11:07.720 these have good support these days. Except for Shell, which I wanted to show, this is a transcript 11:07.720 --> 11:20.120 that sends email. It sends value email. And that's all that's needed. Again, you see, I specify 11:20.120 --> 11:25.720 the content type, text plane, charge it. You don't need to do anything more. There's no my 11:25.720 --> 11:44.280 time encoding to do. It's just become pleasant. Oh, well, the date is needed to be valid, 11:44.280 --> 11:49.720 but that's not speaking SMTP, that's right. It's speaking to user as been sent mail 11:49.880 --> 12:04.200 with minus T option, which will add a date. Sorry? Or the assumption was that for submission, 12:04.200 --> 12:11.720 which is connecting to port 587, or these days for 65, you're not required to add a date? 12:12.600 --> 12:21.000 I don't remember. I should remember, I reviewed that RFC, but I don't remember. 12:25.960 --> 12:31.640 You are not required. There is a should in the RFC that says that the submission service should add 12:31.640 --> 12:39.800 date and message ID. I also wanted to talk a bit about developments now. 12:42.600 --> 12:50.840 Three standard draw immunizations are working on this. I like to think that two of them are 12:50.840 --> 12:59.960 working on it because I've tested people nicely. First, the ITF, which is kind of my home, 13:02.520 --> 13:09.160 it's sad to say that some people don't want to have email address that can contain all 13:09.160 --> 13:17.400 of UTF8. Some people don't like to see soft hyphens in email addresses and protest against it 13:17.400 --> 13:26.120 and don't want to implement that in their codes. So we have a couple of documents with me as older 13:26.200 --> 13:41.720 to restrict that little bit. So that, for example, web forms don't need to accept soft hyphens 13:41.720 --> 13:54.040 in email addresses in order to accept these extensions. The rough syntax is pretty much that 13:55.000 --> 14:01.240 if people can read it, if there's someone who can read it, then it's legal. If not, there's not. 14:02.200 --> 14:07.480 So mixing something like Tana in the local part, Tana is a language spoken on the 14:07.480 --> 14:24.600 Maldives, with, say, Canadian, I forgot from the name, Canadian Indians use, in the 14:24.600 --> 14:28.520 domain, would not be legal because there's no community that uses that combination. 14:28.840 --> 14:39.320 We have some documents to just fix bugs and to be able to use UTF8 in the main context. 14:40.200 --> 14:47.640 And then there's a fund document to help Quebec have a domain spelled in French and one in English 14:47.720 --> 15:03.640 because Quebec has an accent in French. Further, the web bosses are adapting the HTML standards 15:03.640 --> 15:10.120 to support web forms. Extremely important because people enter their email addresses in so many forms 15:11.080 --> 15:18.680 and lost a note least. You see the sentence here does not contain a URL. However, 15:19.480 --> 15:25.160 the magnificent program that I used to make these slides is called Outlook. No, it's not 15:25.160 --> 15:35.240 this called PowerPoints. Recognize that this is a URL. The way that happens is not standardized now 15:35.320 --> 15:43.160 and it is slightly different. If you post this, for example, to Facebook, 15:44.040 --> 15:49.560 it will be recognized as a link. However, if this were a dot i and the main, 15:50.360 --> 16:00.600 then Facebook wouldn't recognize it for reasons. The unique of the consortium is working on 16:00.600 --> 16:11.080 something thorough to make a sensible standard for that which also covers email addresses, 16:11.080 --> 16:20.360 covered books, links and email addresses. I would hope that when that comes out a bunch of PHP, 16:20.840 --> 16:33.880 Ruby, Python and Markdown Software is updated to recognize the main uniformly. 16:37.160 --> 16:43.160 Right, I'm also required to have contact stuff at the end. Please do email me for anything about that. 16:43.160 --> 16:48.920 Particularly if you have a problem relating to any of this, I need to know about all the problems. 16:49.880 --> 16:57.960 I wish there were fewer. Yeah, that's pretty much all I wanted to say. They extended my 16:57.960 --> 17:04.840 talk a little bit after you. Oh, right. And required to have this as well. Even the Twitter link. 17:18.920 --> 17:40.440 Right, and the question was, in the link recognition graph, do I know where a 17:40.440 --> 17:47.480 unicorn is doing some sort of database look up to recognize the mains? In the present graph, 17:47.480 --> 17:56.040 they are not. They use a fixed list which is supposed to be updated in every unicode version 17:56.040 --> 18:04.920 from the iana. Since unicode is updated fairly often, I think this is a reasonable solution. 18:05.880 --> 18:15.400 They also have a similar set of tables for which characters are permitted there. For example, 18:17.240 --> 18:24.920 if there's a parenthesis around all this, then they have similar tables published along with 18:24.920 --> 18:31.320 unicode that say what kind of characters are parenthesis that should go around the link and what 18:31.960 --> 18:39.960 should continue the link. It's all really thoughtful but published with unicode versions not every week. 18:43.400 --> 18:47.800 Yep. Sorry, I was not here from very good in the beginning with the presentation, 18:48.520 --> 18:55.480 but I have a question. Why do you think that unicode being a address is good? Why? Because 18:55.480 --> 19:01.880 whole world, the whole everything that I use is an ASEAN support ASEAN. How are you guys liking an 19:01.880 --> 19:10.200 address or something like you have there? Oh, we are going to open the slash. How will I type that 19:10.200 --> 19:15.720 in my keyboard? How am I going to contact you? The question was, why do I think that unicode 19:15.800 --> 19:29.000 need an address is good and lots more but that's the gist of it. The short answer is that 19:30.840 --> 19:41.240 ASCII disenfranchises a lot of people. We currently have some, actually I don't care very 19:41.320 --> 19:49.480 much about that particular group. We have about 20,000 domains in Russia that are used primarily 19:49.480 --> 19:59.720 for email. Now they could use ASCII, but it's a society that largely uses Cyrilic. Over in China 19:59.720 --> 20:09.160 we have six digits and I care more about that because I personally really do not want to fragment 20:09.240 --> 20:15.480 the internet into two along the great work firewall. It's important to me personally that we have 20:15.480 --> 20:25.080 one internet and that people, and that people's software can send email to other people's software. 20:27.160 --> 20:32.680 Towards the end of the question, why should you be able to do that when you cannot enter the 20:32.760 --> 20:43.560 Chinese email address? The answer to that part is that the 300 million Chinese who 20:44.600 --> 20:53.400 pretty much cannot type any A to Z except you would not be able to read your email at 20:53.400 --> 20:59.640 your email anyway unless you know Chinese. So if you can communicate with these people 20:59.720 --> 21:07.080 then you are able to type something that they can read. If you cannot type something that they can 21:07.080 --> 21:15.240 read then it really doesn't matter where you could type their email address. For communication 21:15.240 --> 21:20.040 you need email address, you need subject, you need body text, you need all of those. Having one of 21:20.040 --> 21:27.720 them doesn't get you anywhere. But you need to do the same applies also to numbers, you know 21:27.720 --> 21:36.520 the we use the numbers, we have generic phone numbers, you can call it whole. And it doesn't 21:36.520 --> 21:42.760 the same question, it doesn't the same apply to film numbers and the obvious that the film 21:42.760 --> 21:50.440 numbers are pretty much bulldozing across the world and they are pushing the Arabs to use 21:53.000 --> 22:01.080 to use Arabic digits. That's right, even in the countries that didn't use Arabic digits to begin with 22:03.640 --> 22:11.800 they are pushing everyone to use digits by force. Is this good or bad? Well, 22:12.040 --> 22:16.920 I'm part of team email. I would like people to use more email and fewer phone numbers. 22:17.960 --> 22:24.840 But obviously they can use phone numbers. If people want to communicate by WhatsApp they can do that. 22:26.840 --> 22:29.080 I'm part of team email and I have my opinion. 22:29.080 --> 22:52.760 Well, I should, if you down those, where do I have those? If you don't know the PDF, those two 22:52.840 --> 23:01.720 are links. If not, I'll paste the links in the chat room afterwards. And I should repeat 23:01.720 --> 23:09.160 to the questions, sorry. In the back? Question was are 23:09.160 --> 23:17.640 including other than UTIF8 supported? No. There is only UTIF8. This was a design decision. 23:18.360 --> 23:29.800 The wasn't experiment. The bugging was too hard. After that test that it was pretty much 23:29.800 --> 23:38.120 decided that the only way forward is to say everything is UTIF8. We don't have anything to say 23:39.000 --> 23:46.520 which part is UTIF8 and which part is not. I'm not sure exactly what the Chinese government 23:46.600 --> 23:51.400 thinks about this. They have their own almost UTIF8. But that's how it is. 23:54.520 --> 24:01.720 In front? What about Windows? Question was what about Windows? 24:03.720 --> 24:08.440 Microsoft popular management issued a decree to everyone some 24:08.440 --> 24:14.680 six or seven years ago saying Windows is for everyone on this website. It's active in a 24:14.680 --> 24:26.040 couple of years. Microsoft software will support this completely. No if no but do it and it was done. 24:26.920 --> 24:33.160 Microsoft had more mail clients, more mail service than they could count. They did it for all of them. 24:33.160 --> 24:39.640 Really quite impressed. Then management started to forget about it and our bugs are creeping in.