[UA-discuss] Legacy Technologies and Universal Acceptance

Jothan Frakes jothan at jothan.com
Mon Jul 22 20:45:47 UTC 2019

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

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,


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

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190722/835c2fd4/attachment.html>

More information about the UA-discuss mailing list