Sorry I missed the call today, the time is in conflict with a policy group meeting for the ICANN Registrars as well as an impromptu meeting of the Domain Name Association.

@Michael I have been very refreshed by your questions, rhetorical or not, about some of the UA areas - especially with respect to evolving legacy systems, These are very similar to the overarching 'Y2K without the urgency of a date' aspects of the challenges within solving many aspects of UA.

There are still systems out there that incorporate mainframe or other client software that were robust enough to address their core functionality requirements - often absent the many advances and evolutionary changes that may not have been known or within project scope.

What I suspect is the case, is that most of those of us who have been dedicated to some form of UA have focused in the areas that have the most benefit and advantage, or that can be the most positive impact. Meanwhile, some natural evolution happens with many of the legacy systems to where they are replaced vs retrofitted, so the types of instances you mention are hopefully on the decline in numbers. I don't speak for everyone, and I am not saying that they are not likely important, but rather, there might be a belief that issues like those you raise may sort themselves out along the way while we are dealing with the big buckets like EAI in current clients, etc.

-Jothan

On Mon, Jul 22, 2019 at 11:38 AM Michael Casadevall <michael@casadevall.pro> wrote:

Hey all,

So following with the Tech WG call earlier today, I branched a question
on legacy technologies and their interactions with UASG. I don't think
it's a secret that a *lot* of infrastructure on the Internet often runs
on either old versions of modern programming languages, is entirely
obsolete, or otherwise not the forefront for new developments.

I want to open a broader discussion on how we should handle these types
of cases; i.e., document ways to implement/store IDN/EAIs?

For context, here's a few places where Unicode either wasn't supported
at the time, or are just obsolete but still common. This isn't an
exhaustive list, just an idea of the types of systems that I know are
still around at least to some extent.

== Mainframe Systems/EBCDIC ==

Mainframes aren't obsolete by any measure, but due to backwards
compatibility, most of them don't even use ASCII as a standard encoding
but the EBCDIC specification, such as z/OS. Often times these systems
host databases and reporting software (Mainframe DB2, not to be confused
with the more common DB2), and still have production code written in
COBOL, RPG, and other programming languages that have moved on to
greener pastures.

While these systems may not necessarily be directly webfacing, storing
user information and email addresses (as well as communication with SMTP
servers) is common, as well as text based systems interacting with these
in the form of terminal emulator/3270 entry systems.

== Visual Basic 6/ASP (not .NET) ===

VB6 is (sadly) not dead, and I know a fair number of organizations which
can't migrate to VB.NET. The basic String data type in VB6 does support
Unicode due to its COM hertiage, but much of the VB6 ecosystem still
runs on codepages and older technologies for internationalization
support. That being said, having a COM object for EAI/IDNs is much more
doable here than some other systems.

== dBase ==
Still exists (http://www.dbase.com/), and even still supports the
MS-DOS versions (last update 2018!). There's no public documentation
that I can find in a brief glance that talks about Unicode support.

Obviously I could find more, but this gives an operating system,
programming language, and database where Unicode is either non-standard
or non-existent but may be used with handling IDN or EAI storage.
Michael

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.