<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello, UA colleagues:</p>
<p>Two weeks ago we had a thread about my interest in seeing
Universal Acceptance proposals submitted to the 41st
Internationalization and Unicode Conference (IUC41). Based on
that discussion, I am working on a proposal for a 50-minute
presentation. I'd like to run these by you for your information. I
appreciate any feedback you have.</p>
<hr size="2" width="100%">
<p><b>Presentation title</b>: Universal Acceptance of non-Latin
email addresses and domain names: how does your framework rate?</p>
<p><b>Abstract</b>:</p>
<p>The next one billion internet users use a wide variety of
languages and scripts. They will demand email addresses, and
domain names, in scripts they can easily read. App development
frameworks, libraries, and programming languages on all platforms
will be called on to meet this challenge. This is Universal
Acceptance (UA) — of all domain names and email addresses, from
<a class="moz-txt-link-freetext" href="http://普遍接受-测试。世界">http://普遍接受-测试。世界</a> [simplifed Chinese] to مانيش @ أشوكا. الهند
[arabic] to données@fußballplatz.technology [latin non-ASCII]. We
present technical compliance criteria, a list of problem areas,
and ways to evaluate compliance. We give our compliance findings
so far. Does your library and platform provide Universal
Acceptance? <br>
<br>
Universal Acceptance is a foundational requirement for a truly
multilingual Internet, one in which users around the world can
navigate entirely in local languages. It is also the key to
unlocking the potential of new generic top-level domains (gTLDs)
to foster competition, consumer choice and innovation in the
domain name industry. To achieve Universal Acceptance, Internet
applications and systems must treat all TLDs in a consistent
manner, including new gTLDs and internationalized TLDs.
Specifically, they must accept, validate, store, process and
display all domain names and email addresses.<br>
<br>
This talk presents a compliance review plan, for the programming
languages and frameworks with which applications are built. It has
a list of UA features to check, and gives reference correct
results. Application developers can use these tests to be sure the
tools they use afford Universal Acceptance. Framework developers
can use these tests to be sure that they provide access to the
right scope of Universal Acceptance functionality, and that it
works well. There is a complementary compliance review plan of
application features, which we will also look at.<br>
<br>
This compliance review plan are the work of the Universal
Acceptance Steering Group (<a class="moz-txt-link-freetext" href="https://uasg.tech/">https://uasg.tech/</a>). An ICANN project,
the UASG is a community-based team working to share this vision
for the Internet of the future with those who construct this
space: coders. The group’s primary objective is to help software
developers and website owners understand how to update their
systems to keep pace with an evolving domain name system (DNS).<br>
<br>
The UASG has done its own compliance evaluation for selected
frameworks and programming languages. We will go over these
results. <br>
<br>
This talk is complementary with Dr Ajay Data's presentation on
Data Xgen's experience developing email services with non-Latin
email addresses and domain names. <br>
<br>
This talk is suitable for product owners, application developers,
programming language and framework developers, testers, domain
registars, email hosting companies, management, and developers.
Plus, anyone who looks forward to using email addresses and domain
names in non-Latin scripts will find this evaluation of interest.</p>
<p>[Note: I plan to base this mainly on the contents of "Reviewing
programming languages and frameworks for compliance with Universal
Acceptance good practice"]</p>
<p><b>Ram and other leaders</b>: Is it all right for me to identify
myself as a member of UASG, and this talk as being a UASG
presentation, and use the UASG templates? I don't mind just
proposing an individual talk, but I think having the UASG branding
would be stronger.<br>
</p>
<hr size="2" width="100%">
<p>I am also working on a proposal for a 1.5 hour tutorial. <br>
</p>
<p><b>Tutorial Title</b>: Domain names and email addresses aren't
just ASCII anymore. Now what?</p>
<p><b>Tutorial Concept</b>: Explain IDN and EAI, and their
implications, for an audience that doesn't know either. The next
billion internet users. Explain Punycode and how it's the ASCII
labels that are registered. Show the thousands of gTLDs, and how
to get the current list. Talk about policy issues like joint
registration. Talk about confusables, as a security issue and a
trademark issue. Introduce UASG and other groups working on these
issues. Review the portfolio of UASG materials and how
participants can apply them, both to the software they developed,
and to that they procure.<br>
</p>
<p>I think the tutorial extends beyond UASG, so I'm leaning towards
presenting it as an individual tutorial.</p>
<p>N.B. It's my practice to freely licence my presentation materials
with CC-BY, so they will be available for others to re-use. <br>
</p>
<p>Also, as alluded to above, I understand that Dr Ajay Data has
proposed a presentation on Data Xgen's experience developing email
services with non-Latin email addresses and domain names. I think
this will be interesting by itself, and even better in combination
with the UASG material in my proposal.</p>
<p>Who knows whether the program committee will accept any of these
proposals? They will give us their answer towards the end of
April.</p>
<p>One final reminder: if anyone else wants to propose a talk, 24.
March is the deadline! Details at <<a
href="http://www.unicodeconference.org/call-for-participation.htm">http://www.unicodeconference.org/call-for-participation.htm</a>>.<br>
</p>
Once again, your feedback is welcome. Best regards,<br>
--Jim DeLaHunt<br>
<br>
<pre class="moz-signature" cols="72">--
--Jim DeLaHunt, <a class="moz-txt-link-abbreviated" href="mailto:jdlh@jdlh.com">jdlh@jdlh.com</a> <a class="moz-txt-link-freetext" href="http://blog.jdlh.com/">http://blog.jdlh.com/</a> (<a class="moz-txt-link-freetext" href="http://jdlh.com/">http://jdlh.com/</a>)
multilingual websites consultant
355-1027 Davie St, Vancouver BC V6E 4L2, Canada
Canada mobile +1-604-376-8953
</pre>
</body>
</html>