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.