Hi all I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes. The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access. The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large. In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors. Cheers, Roberto
A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user. Many thanks Roberto. Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
I would add, however, the observation that a large amount of internet traffic does not involve humans at all. Rather it is device-to-device traffic. I work with trying to test and improve the resilience of devices to real or potential, but usually inadequately tested conditions. Many devices wobble or simply fail when they face conditions beyond the nice, calm networks of their developers. Those conditions may be caused by natural conditions or otherwise. I have, for example, seen how the introduction of new devices, that may speak a slightly different (but fully RFC compliant) version of a protocol can knock-out what were previous stable devices on the network. One of favorite examples comes from the days when we still had TCP/IP bakeoffs when the introduction of a single PC using FTP Software's stack could crash any and every instance of machines running one of the their competitor's protocol stacks - the cause was simply that they they sent a sequence of IP fragments with the last fragment first (which allows the receiver to better optimize its buffer space). That's 100% RFC legitimate, but it crashed other devices. Back to UA - We usually forget that anything beyond the most basic cases will be mis- or weakly implemented and inadequately tested - and thus potentially subject to outages due to "unusual" network traffic. I have fear that the "U" part in "UA" efforts will drive the addition of that kind of mis- or weakly implemented UA code in devices that almost always will not have any operational reason to go beyond classic ASCII. Such devices may be in critical roles - self driving vehicles, power plant controls, etc etc. (An appropriate protective strategy for such devices might simply be for them to silently reject and drop anything that is not ASCII rather than trying to deal with it.) I have a Tesla automobile. It is already filled with some really badly designed and badly written code. Automobiles are already speaking TCP/IP on automotive Ethernets that are sometimes connected to the outside world. A typical vehicle of today may have hundreds of processors attached-to and chatting-on those internet networks. I fear further risks should, hypothetically, should something like a Unicode string get onto a controller net in a car and cause something like a brake anti-lock/stability-control processor to go awry. (I've already experienced what can happen when a stability control system goes bad - it can be a shockingly terrifying experience, especially if it happens on a crowded highway downhill curve at high speed.) (And I am reminded of the fate of the Mars Climate Orbiter when a mismatch between US measurements [inches, feet] and metric measurements caused the probe to crash.) As a kid I worked with my grandfather and father repairing TVs - ones with vacuum tubes! Those boxes were very sensitive to less-than usual operating conditions - like being used on the same power circuit as a refrigerator that had a motor that generated noise onto the utility power wiring in a house. In those days there was a joke that was quite applicable: A person goes to a Doctor and says it hurts when I do this (and demonstrates some activity that constitutes "this"). The Doctor's reply is: Then stop doing that. Same for UA. Perhaps the "Universal" part needs to be de-emphasised by a recognition that there will be large parts of our internet for which that is not necessary, could add costs, and, worse, could create risks. --karl-- On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote:
A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user.
Many thanks Roberto.
Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround/ =============================
On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large <at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site:http://atlarge.icann.org _______________________________________________ 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.
Hi Karl I am not sure to understand correctly. Are you saying that farmers in Bangladesh, as an example, should not have access to the Internet in their language and script because of some bad code in Tesla cars? I hope I have misunderstood, please clarify. Cheers, Roberto Inviato da iPad Il giorno 29.03.2024, alle ore 18:36, Karl Auerbach <karl@cavebear.com> ha scritto: I would add, however, the observation that a large amount of internet traffic does not involve humans at all. Rather it is device-to-device traffic. I work with trying to test and improve the resilience of devices to real or potential, but usually inadequately tested conditions. Many devices wobble or simply fail when they face conditions beyond the nice, calm networks of their developers. Those conditions may be caused by natural conditions or otherwise. I have, for example, seen how the introduction of new devices, that may speak a slightly different (but fully RFC compliant) version of a protocol can knock-out what were previous stable devices on the network. One of favorite examples comes from the days when we still had TCP/IP bakeoffs when the introduction of a single PC using FTP Software's stack could crash any and every instance of machines running one of the their competitor's protocol stacks - the cause was simply that they they sent a sequence of IP fragments with the last fragment first (which allows the receiver to better optimize its buffer space). That's 100% RFC legitimate, but it crashed other devices. Back to UA - We usually forget that anything beyond the most basic cases will be mis- or weakly implemented and inadequately tested - and thus potentially subject to outages due to "unusual" network traffic. I have fear that the "U" part in "UA" efforts will drive the addition of that kind of mis- or weakly implemented UA code in devices that almost always will not have any operational reason to go beyond classic ASCII. Such devices may be in critical roles - self driving vehicles, power plant controls, etc etc. (An appropriate protective strategy for such devices might simply be for them to silently reject and drop anything that is not ASCII rather than trying to deal with it.) I have a Tesla automobile. It is already filled with some really badly designed and badly written code. Automobiles are already speaking TCP/IP on automotive Ethernets that are sometimes connected to the outside world. A typical vehicle of today may have hundreds of processors attached-to and chatting-on those internet networks. I fear further risks should, hypothetically, should something like a Unicode string get onto a controller net in a car and cause something like a brake anti-lock/stability-control processor to go awry. (I've already experienced what can happen when a stability control system goes bad - it can be a shockingly terrifying experience, especially if it happens on a crowded highway downhill curve at high speed.) (And I am reminded of the fate of the Mars Climate Orbiter when a mismatch between US measurements [inches, feet] and metric measurements caused the probe to crash.) As a kid I worked with my grandfather and father repairing TVs - ones with vacuum tubes! Those boxes were very sensitive to less-than usual operating conditions - like being used on the same power circuit as a refrigerator that had a motor that generated noise onto the utility power wiring in a house. In those days there was a joke that was quite applicable: A person goes to a Doctor and says it hurts when I do this (and demonstrates some activity that constitutes "this"). The Doctor's reply is: Then stop doing that. Same for UA. Perhaps the "Universal" part needs to be de-emphasised by a recognition that there will be large parts of our internet for which that is not necessary, could add costs, and, worse, could create risks. --karl-- On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote: A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user. Many thanks Roberto. Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround ============================= On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large <at-large@atlarge-lists.icann.org<mailto:at-large@atlarge-lists.icann.org>> wrote: Hi all I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes. The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access. The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large. In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors. Cheers, Roberto _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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. _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
No, what I am saying is that things like embedded device controllers ought not to be forced (or even socially coerced) to bear the risks of running UA code that will almost certainly (for those devices) almost never tested and may create vulnerabilities. Our internet is already dangerously vulnerable and brittle, we don't need to make it worse in the areas that we least see (such as the area of device controllers.) --karl-- On 3/29/24 11:01 AM, Roberto Gaetano wrote:
Hi Karl
I am not sure to understand correctly. Are you saying that farmers in Bangladesh, as an example, should not have access to the Internet in their language and script because of some bad code in Tesla cars?
I hope I have misunderstood, please clarify.
Cheers, Roberto
Inviato da iPad
Il giorno 29.03.2024, alle ore 18:36, Karl Auerbach <karl@cavebear.com> ha scritto:
I would add, however, the observation that a large amount of internet traffic does not involve humans at all. Rather it is device-to-device traffic.
I work with trying to test and improve the resilience of devices to real or potential, but usually inadequately tested conditions. Many devices wobble or simply fail when they face conditions beyond the nice, calm networks of their developers. Those conditions may be caused by natural conditions or otherwise.
I have, for example, seen how the introduction of new devices, that may speak a slightly different (but fully RFC compliant) version of a protocol can knock-out what were previous stable devices on the network. One of favorite examples comes from the days when we still had TCP/IP bakeoffs when the introduction of a single PC using FTP Software's stack could crash any and every instance of machines running one of the their competitor's protocol stacks - the cause was simply that they they sent a sequence of IP fragments with the last fragment first (which allows the receiver to better optimize its buffer space). That's 100% RFC legitimate, but it crashed other devices.
Back to UA - We usually forget that anything beyond the most basic cases will be mis- or weakly implemented and inadequately tested - and thus potentially subject to outages due to "unusual" network traffic.
I have fear that the "U" part in "UA" efforts will drive the addition of that kind of mis- or weakly implemented UA code in devices that almost always will not have any operational reason to go beyond classic ASCII. Such devices may be in critical roles - self driving vehicles, power plant controls, etc etc. (An appropriate protective strategy for such devices might simply be for them to silently reject and drop anything that is not ASCII rather than trying to deal with it.)
I have a Tesla automobile. It is already filled with some really badly designed and badly written code. Automobiles are already speaking TCP/IP on automotive Ethernets that are sometimes connected to the outside world. A typical vehicle of today may have hundreds of processors attached-to and chatting-on those internet networks. I fear further risks should, hypothetically, should something like a Unicode string get onto a controller net in a car and cause something like a brake anti-lock/stability-control processor to go awry. (I've already experienced what can happen when a stability control system goes bad - it can be a shockingly terrifying experience, especially if it happens on a crowded highway downhill curve at high speed.) (And I am reminded of the fate of the Mars Climate Orbiter when a mismatch between US measurements [inches, feet] and metric measurements caused the probe to crash.)
As a kid I worked with my grandfather and father repairing TVs - ones with vacuum tubes! Those boxes were very sensitive to less-than usual operating conditions - like being used on the same power circuit as a refrigerator that had a motor that generated noise onto the utility power wiring in a house. In those days there was a joke that was quite applicable: A person goes to a Doctor and says it hurts when I do this (and demonstrates some activity that constitutes "this"). The Doctor's reply is: Then stop doing that.
Same for UA. Perhaps the "Universal" part needs to be de-emphasised by a recognition that there will be large parts of our internet for which that is not necessary, could add costs, and, worse, could create risks.
--karl--
On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote:
A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user.
Many thanks Roberto.
Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround/ =============================
On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large <at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site:http://atlarge.icann.org _______________________________________________ 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.
Agreed, Karl. No one should have code foisted upon them. The code is optional. The social coercion is simply to get systems capable of handling both longer and IDN TLDs. That's browsers, email, websites, etc. I doubt it would ever include embedded code. I guess if your Tesla asked you for an email address because it's sends you emails when warning lights come on, it would ideally be able to handle all email addresses. The code is there to help you but you or I could write our own code in an afternoon to be sure of what we were including. Jonathan ________________________________ From: At-Large <at-large-bounces@atlarge-lists.icann.org> on behalf of Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> Sent: Friday, March 29, 2024 11:33 AM To: Roberto Gaetano <roberto_gaetano@hotmail.com> Cc: At Large <at-large@atlarge-lists.icann.org>; EURALO Discuss <euro-discuss@atlarge-lists.icann.org> Subject: Re: [At-Large] UA Days No, what I am saying is that things like embedded device controllers ought not to be forced (or even socially coerced) to bear the risks of running UA code that will almost certainly (for those devices) almost never tested and may create vulnerabilities. Our internet is already dangerously vulnerable and brittle, we don't need to make it worse in the areas that we least see (such as the area of device controllers.) --karl-- On 3/29/24 11:01 AM, Roberto Gaetano wrote: Hi Karl I am not sure to understand correctly. Are you saying that farmers in Bangladesh, as an example, should not have access to the Internet in their language and script because of some bad code in Tesla cars? I hope I have misunderstood, please clarify. Cheers, Roberto Inviato da iPad Il giorno 29.03.2024, alle ore 18:36, Karl Auerbach <karl@cavebear.com><mailto:karl@cavebear.com> ha scritto: I would add, however, the observation that a large amount of internet traffic does not involve humans at all. Rather it is device-to-device traffic. I work with trying to test and improve the resilience of devices to real or potential, but usually inadequately tested conditions. Many devices wobble or simply fail when they face conditions beyond the nice, calm networks of their developers. Those conditions may be caused by natural conditions or otherwise. I have, for example, seen how the introduction of new devices, that may speak a slightly different (but fully RFC compliant) version of a protocol can knock-out what were previous stable devices on the network. One of favorite examples comes from the days when we still had TCP/IP bakeoffs when the introduction of a single PC using FTP Software's stack could crash any and every instance of machines running one of the their competitor's protocol stacks - the cause was simply that they they sent a sequence of IP fragments with the last fragment first (which allows the receiver to better optimize its buffer space). That's 100% RFC legitimate, but it crashed other devices. Back to UA - We usually forget that anything beyond the most basic cases will be mis- or weakly implemented and inadequately tested - and thus potentially subject to outages due to "unusual" network traffic. I have fear that the "U" part in "UA" efforts will drive the addition of that kind of mis- or weakly implemented UA code in devices that almost always will not have any operational reason to go beyond classic ASCII. Such devices may be in critical roles - self driving vehicles, power plant controls, etc etc. (An appropriate protective strategy for such devices might simply be for them to silently reject and drop anything that is not ASCII rather than trying to deal with it.) I have a Tesla automobile. It is already filled with some really badly designed and badly written code. Automobiles are already speaking TCP/IP on automotive Ethernets that are sometimes connected to the outside world. A typical vehicle of today may have hundreds of processors attached-to and chatting-on those internet networks. I fear further risks should, hypothetically, should something like a Unicode string get onto a controller net in a car and cause something like a brake anti-lock/stability-control processor to go awry. (I've already experienced what can happen when a stability control system goes bad - it can be a shockingly terrifying experience, especially if it happens on a crowded highway downhill curve at high speed.) (And I am reminded of the fate of the Mars Climate Orbiter when a mismatch between US measurements [inches, feet] and metric measurements caused the probe to crash.) As a kid I worked with my grandfather and father repairing TVs - ones with vacuum tubes! Those boxes were very sensitive to less-than usual operating conditions - like being used on the same power circuit as a refrigerator that had a motor that generated noise onto the utility power wiring in a house. In those days there was a joke that was quite applicable: A person goes to a Doctor and says it hurts when I do this (and demonstrates some activity that constitutes "this"). The Doctor's reply is: Then stop doing that. Same for UA. Perhaps the "Universal" part needs to be de-emphasised by a recognition that there will be large parts of our internet for which that is not necessary, could add costs, and, worse, could create risks. --karl-- On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote: A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user. Many thanks Roberto. Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround ============================= On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large <at-large@atlarge-lists.icann.org<mailto:at-large@atlarge-lists.icann.org>> wrote: Hi all I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes. The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access. The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large. In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors. Cheers, Roberto _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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. _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
I certainly agree that nobody should have code "foisted upon them". That said, one significant impediment to UA can be a simple inability (or lack of resources) to create the necessary code. Sometimes that will, as noted, result in bad/unreliable code. Sometimes, it will result in no code at all -- not from unwillingness to implement UA, but from simple inability. The obvious solution would be for ICANN to make available basic UA modules. We couldn't cover every coding language, of course. But we could hit the major ones. If we don't have the necessary expertise in house, rent-a-coders are dirt cheap. Bill Jouris Yahoo Mail: Search, Organize, Conquer On Fri, Mar 29, 2024 at 11:42 AM, Jonathan Zuck via At-Large<at-large@atlarge-lists.icann.org> wrote: _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
I was following UASG from its initial days I am wholeheartedly agree with the feeling that Users/ At-Large should be a key point in it's focus And while mentioning it I like to point 2 trends I observed On initial focus , developer adoption to programming languages and platforms was a focus with a clear plan around open source systems compatibility with UA . But somehow over a period leadership focus shifted to building a CXO agenda around UA I think essentially this gap still exists , adoption in programming languages and platforms is still minimal , and the ongoing AI rush is making it difficult to At-Large adoption , since AI tokenization is going to be costly in complex script low resource world languages in East Asia, South Asia , Central Asia , Africa and Uralic languages in Europe And while we mention users, the maker vs consumer divide exists So far user/at-large focus on UA day was more on consumer side while Developer/maker adoption is lagging . this is because the community came up on UA was mostly user adoption focused . I think there is a need of a fresh look and prioritization if we need to fast-track UA. In addition more tech side issues exists like IDNA2008 adoption (which will change a lot if existing technical specs around LGRs due to shaping characters coming as identifiers ) , but there is a lack of attention or expertise I can see in this domain I know this mail will be little off-topic, but developer adoption(Maker side of Users At-Large) bigger lagging ground for UASG these days Anivar On Sat, 30 Mar, 2024, 10:59 Bill Jouris via At-Large, < at-large@atlarge-lists.icann.org> wrote:
I certainly agree that nobody should have code "foisted upon them". That said, one significant impediment to UA can be a simple inability (or lack of resources) to create the necessary code. Sometimes that will, as noted, result in bad/unreliable code. Sometimes, it will result in no code at all -- not from unwillingness to implement UA, but from simple inability.
The obvious solution would be for ICANN to make available basic UA modules. We couldn't cover every coding language, of course. But we could hit the major ones. If we don't have the necessary expertise in house, rent-a-coders are dirt cheap.
Bill Jouris
Yahoo Mail: Search, Organize, Conquer <https://mail.onelink.me/107872968?pid=NativePlacement&c=Global_Acquisition_Y...>
On Fri, Mar 29, 2024 at 11:42 AM, Jonathan Zuck via At-Large <at-large@atlarge-lists.icann.org> wrote: _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Karl, You bring important points to the discussion. Our daily internet use hides a bustling world of devices talking to each other, from smart thermostats to fitness trackers. This device-to-device communication (D2D) is essential, but challenges arise. Devices might not be fully tested for real-world internet quirks, and slight variations in how they speak the same language can cause problems. Efforts to make devices accept all information can be risky for critical systems like cars or medical equipment. Just like ensuring smooth conversations between people, we need to make sure these silent exchanges run safely to keep our devices working as expected. Your statement argues against forcing embedded device controllers to run Universal Acceptance (UA) code for several reasons: - *Security Risks:* Embedded devices often control critical functions and are rarely tested for complex code like UA. Running UA code on them significantly increases the risk of vulnerabilities that could be exploited by attackers. - *Unnecessary Burden:* Most embedded devices have limited functionality and don't need to understand a wide range of information. UA forces them to handle potentially risky data they're not designed for. - *Fragile Infrastructure:* The internet is already vulnerable, and adding complexities like untested UA code on embedded devices only makes it more fragile and prone to widespread disruptions. If it is dangerous to make these essential, often unseen devices handle complex tasks they're not built for, this could create new security holes and make the entire internet infrastructure even more vulnerable, especially when these devices have an international/global purpose. My 2cents! [image: photo] [image: photo] Alfredo Calderon eLearning Consultant aprendizajedistancia.blogspot.com calderon.alfredo@gmail.com | wiseintro.co/alfredocalderon | Alfredo_1212 | Virtual School on Internet Governance | https://virtualsig.org [image: facebook] <https://facebook.com/calderon.alfredo> [image: linkedin] <https://pr.linkedin.com/in/acalderon52> [image: twitter] <https://twitter.com/acalderon52> [image: pinterest] <http://www.pinterest.com/acalderon/> [image: slideshare] <http://www.slideshare.net/acalderon> [image: twitter] <https://twitter.com/virtualschoolIG> [image: wiseintro] <https://wiseintro.co/alfredocalderon> IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof. Create your WiseStamp email signature <https://www.wisestamp.com/lp/promo/professional-email-signature?utm_source=p...> [image: __tpx__] On Fri, Mar 29, 2024 at 2:33 PM Karl Auerbach via At-Large < at-large@atlarge-lists.icann.org> wrote:
No, what I am saying is that things like embedded device controllers ought not to be forced (or even socially coerced) to bear the risks of running UA code that will almost certainly (for those devices) almost never tested and may create vulnerabilities.
Our internet is already dangerously vulnerable and brittle, we don't need to make it worse in the areas that we least see (such as the area of device controllers.)
--karl-- On 3/29/24 11:01 AM, Roberto Gaetano wrote:
Hi Karl
I am not sure to understand correctly. Are you saying that farmers in Bangladesh, as an example, should not have access to the Internet in their language and script because of some bad code in Tesla cars?
I hope I have misunderstood, please clarify.
Cheers, Roberto
Inviato da iPad
Il giorno 29.03.2024, alle ore 18:36, Karl Auerbach <karl@cavebear.com> <karl@cavebear.com> ha scritto:
I would add, however, the observation that a large amount of internet traffic does not involve humans at all. Rather it is device-to-device traffic.
I work with trying to test and improve the resilience of devices to real or potential, but usually inadequately tested conditions. Many devices wobble or simply fail when they face conditions beyond the nice, calm networks of their developers. Those conditions may be caused by natural conditions or otherwise.
I have, for example, seen how the introduction of new devices, that may speak a slightly different (but fully RFC compliant) version of a protocol can knock-out what were previous stable devices on the network. One of favorite examples comes from the days when we still had TCP/IP bakeoffs when the introduction of a single PC using FTP Software's stack could crash any and every instance of machines running one of the their competitor's protocol stacks - the cause was simply that they they sent a sequence of IP fragments with the last fragment first (which allows the receiver to better optimize its buffer space). That's 100% RFC legitimate, but it crashed other devices.
Back to UA - We usually forget that anything beyond the most basic cases will be mis- or weakly implemented and inadequately tested - and thus potentially subject to outages due to "unusual" network traffic.
I have fear that the "U" part in "UA" efforts will drive the addition of that kind of mis- or weakly implemented UA code in devices that almost always will not have any operational reason to go beyond classic ASCII. Such devices may be in critical roles - self driving vehicles, power plant controls, etc etc. (An appropriate protective strategy for such devices might simply be for them to silently reject and drop anything that is not ASCII rather than trying to deal with it.)
I have a Tesla automobile. It is already filled with some really badly designed and badly written code. Automobiles are already speaking TCP/IP on automotive Ethernets that are sometimes connected to the outside world. A typical vehicle of today may have hundreds of processors attached-to and chatting-on those internet networks. I fear further risks should, hypothetically, should something like a Unicode string get onto a controller net in a car and cause something like a brake anti-lock/stability-control processor to go awry. (I've already experienced what can happen when a stability control system goes bad - it can be a shockingly terrifying experience, especially if it happens on a crowded highway downhill curve at high speed.) (And I am reminded of the fate of the Mars Climate Orbiter when a mismatch between US measurements [inches, feet] and metric measurements caused the probe to crash.)
As a kid I worked with my grandfather and father repairing TVs - ones with vacuum tubes! Those boxes were very sensitive to less-than usual operating conditions - like being used on the same power circuit as a refrigerator that had a motor that generated noise onto the utility power wiring in a house. In those days there was a joke that was quite applicable: A person goes to a Doctor and says it hurts when I do this (and demonstrates some activity that constitutes "this"). The Doctor's reply is: Then stop doing that.
Same for UA. Perhaps the "Universal" part needs to be de-emphasised by a recognition that there will be large parts of our internet for which that is not necessary, could add costs, and, worse, could create risks.
--karl-- On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote:
A proposition worthy of our support, especially from those of us that are still concerned with equitable Internet access! An insightful view of how a change in the conversation could positively impact the lowly end user.
Many thanks Roberto.
Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround* =============================
On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
_______________________________________________ At-Large mailing listAt-Large@atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Dear Roberto, thank you very much for the report, your point which made such great twist in the discussion (we were especially looking forward to it in Euralo). I support your point of view: the proactivity of users + active supporting role of At-Large, which have links on the ground, points of presence in different regions. It have to become an another big step forward! Safe flight home🌟 Best, Natalia пт, 29 мар. 2024 г., 19:23 Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org>:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Thanks Roberto, good notes. It might be interesting to look back, how it all started and compare it with current situation. I assume majority will agree - we see UA progress. From the end user perspective today local scripts just work and supported in domains, web, social networks and other popular apps. Except emails, but this seems to be non technical problem. I was never convinced this is the must in the past and today younger generation perfectly operate without IDN emails. As a summary should I say this is an example of evolutionary process rather then revolutionary. It took us 10+ years. -- {ak} Пт, 29 марта 2024 г. в 19:23, Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org>:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Thanks very much, Roberto, for your boots-on-the-ground report from the global UA event. I fully support your call for At-Large--the fifth pillar as you have mentioned--to exert its influence to persuade all stakeholders to achieve UA compliance. With kind regards satish On Fri, Mar 29, 2024, 21:53 Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Many thanks Roberto for the useful summary. You raise valid points, great to see ccTLDs at the forefront of Championing Universal Acceptance. Considering the fact that most of them implement the 3 R model, the role of end users as meaningful actors is key. Best Regards On Fri, Mar 29, 2024 at 7:23 PM Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org> wrote:
Hi all
I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes.
The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en
The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access.
The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large.
In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors.
Cheers, Roberto
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
-- Barrack O. Otieno +254721325277 +254733206359 Skype: barrack.otieno PGP ID: 0x2611D86A
Dear Roberto, Thank you for sharing the session brief . I fully agree with you that raising users awareness and knowledge about the possibility of having domain names and email addresses in their own languages is important. I can tell you that nearly every time I participated in a session related to the DNS and/or ICANN and I raised the topic of domain names and IDNs, hardly anyone in the session was aware of the existence of Arabic domain names. How can they demand or understand the need for it when they are barely aware of its existence? Our mission has two aspects: Raising awareness about the existence of IDNs and encouraging users who realize the benefits of IDNs to demand them. I also concur that market surveys, as mentioned by others , are important. Targeted market surveys conducted at a regional and national basis can assist in pinpointing specific areas of focus. Moreover, I believe that after connecting the unconnected, IDNs will play a significant role in actively bringing newly connected users online. Kind regards Hadia Elminiawi From: At-Large <at-large-bounces@atlarge-lists.icann.org> On Behalf Of Roberto Gaetano via At-Large Sent: Friday, March 29, 2024 6:23 PM To: EURALO Discuss <euro-discuss@atlarge-lists.icann.org>; At Large <at-large@atlarge-lists.icann.org> Subject: [External] [At-Large] UA Days Hi all I have attended the UA Days in Belgrade. I am taking the opportunity of a delay in my flight back to drop some notes. The meeting was very interesting. We had a full house in the morning, with numbers decreasing in the afternoon. I don’t know about the online participation. Please find the programme here: https://uaday.rs/program/?lang=en The first panel was about multilingualism, Sally Costerton was among the speakers. It seems that the concept that the ultimate goal is multilingualism in the Internet is taking speed. To be noted that Anil Kumar Jain, UASG Chair, mentioned the four “pillars” among which there is no mention of the role of the user community. Interesting contribution by Leonid Todorov, arguing that we will have a stronger push to UA readiness from places and people that are more disadvantaged rather than from places and people that are better aware - in an intellectual way - about the need for equality of opportunities in internet access. The second panel featured some registries that have been active in achieving results in term of UA readiness. I was the last speaker, and brought the point of view of the users, who are the most affected by lack of UA, making also a couple of examples. The good news is that my contribution was well received, the bad news is that I made the point that the user community should play a role - I argued that it should be the “fifth pillar” in the UA strategy - as users can put pressure on the providers that are not UA ready, proposing that we have a paradigm shift from “providers will graciously become UA compliant as a bonus for the users” to “users worldwide have the right to demand that all users have the same Internet experience regardless their language or script they use”. The bad news is in the fact that I have proposed that the user community - and At-Large at the forefront - use their footprint in the wider community to build awareness of the user rights and produce pressure - also in collaboration with governments - to providers to be UA compliant. That means a call for action for At-Large. In summary, we need to move from being spectators, waiting for things to happen, for the technical community to provide solutions, for providers to deploy UA-compliant services, to an active part of the community to demand and obtain the same level of service for all Internet users, regardless language, script, physical location, or other factors. Cheers, Roberto
Hello Haida, On Wed, Apr 3, 2024 at 5:05 AM Hadia Abdelsalam Mokhtar EL miniawi via At-Large <at-large@atlarge-lists.icann.org> wrote:
I fully agree with you that raising users awareness and knowledge about the possibility of having domain names and email addresses in their own languages is important. I can tell you that nearly every time I participated in a session related to the DNS and/or ICANN and I raised the topic of domain names and IDNs, hardly anyone in the session was aware of the existence of Arabic domain names. How can they demand or understand the need for it when they are barely aware of its existence?
ICANN first published IDN guidelines in 2003 <https://www.icann.org/resources/pages/idn-guidelines-2003-06-20-en>. That there is so little awareness of them after more than 20 years of existence, perhaps suggests that little demand exists. That is, few people, companies or governments are asking ICANN or its community what solutions it is offering so that IDNs may be offered in response. WhatsApp and ChatGPT support more than 50 languages, Facebook more than 100, Google Search and Twitter more than 150 each. Most chat and broadcast platforms as well as applications and operating systems enable Unicode so that anyone can use whatever script their input device can handle. Indeed platforms such as QQ and Yandex were designed primarily for use in non-Latin-script environments. In this world in which people today easily access the Internet in the language of their choice using existing methods on even the simplest of access devices, what specifically is the *public* need for IDNs? Search engines from multiple sources can take a request from anyone in their own script and language, and find the appropriate resource regardless of what its domain name happens to be. This could, indeed, work with a single domain and a flat namespace.
Our mission has two aspects: Raising awareness about the existence of IDNs and encouraging users who realize the benefits of IDNs to demand them.
What reason for confidence do you have that raising awareness of IDNs will create demand that does not yet exist? The technical and government communities within ICANN have had two decades to spread the word about IDN benefits, yet that message has not gained traction far outside the ICANN community. Even UA Day, as an outreach effort, continues to insist on top-down efforts rather than bottom-up. From the ICANN report on last year's UA Day <https://www.icann.org/en/system/files/files/universal-acceptance-day-01jun23...>, *not a single event* anywhere in the world targeted end-users, application developers, or the mainstream news media (page 10 of the report). The "outreach" is only being done to comfortable audiences of insiders who won't ask embarrassing questions like "who actually wants this besides domain sellers?". Meanwhile, the general public of end-users -- the constituency ALAC claims to represent -- employs the many existing, easier and cheaper ways to communicate in any language with each other and with Internet content and services. To me, IDN's current boosters remain because of (a) financial self-interest, (b) the sunk cost of decades of volunteer effort and emotions, and/or (c) their own deep lack of awareness regarding what the world has already done to solve the challenges of multilingual access. The real awareness that I see absent is that IDNs have been met by widespread public indifference, if not rejection, despite 20 years of availability and promotion. A year's worth of more UA days is not going to change that, because simply it's an inferior solution to what has already been solved. Cheers, - Evan
Dear Evan, "Even UA Day, as an outreach effort, continues to insist on top-down efforts rather than bottom-up. From the ICANN report on last year's UA Day <https://www.icann.org/en/system/files/files/universal-acceptance-day-01jun23...> , *not a single event* anywhere in the world targeted end-users, application developers, or the mainstream news media (page 10 of the report). The "outreach" is only being done to comfortable audiences of insiders who won't ask embarrassing questions like "who actually wants this besides domain sellers?". Meanwhile, the general public of end-users -- the constituency ALAC claims to represent -- employs the many existing, easier and cheaper ways to communicate in any language with each other and with Internet content and services." I remember going to Buenos Aires with a great deal of excitement to be part of the team forming LACRALO in the 2000s. As ICT Professional and practitioner this was the opportunity to stop being the front end user and understand what was under the hood. I then went to the Rio meeting and ran into the lawyers and the permanent policy wonks. Quite unnerving at the time. Twenty years later in my neighbourhood ICANN continues to be in rarified air where a minority of us reside. ICANN has gotten very little traction despite significant effort. Some policymakers relate to ITU a lot better because it is felt that they deal with the bread and butter issues (connectivity, community access etc.). ICANN in most instances work on the assumption that these minor matters have been dealt with. Matters such as new gTLDs for example are of no relevance because of cost. If ICANN wants to reach the underserved it has to be seen as useful and actually be relevant. Maybe because of its very nature and structure it cannot reach or help the underserved and therefore focus on those areas that have moved beyond the basics. My mere two cents Lance On Wed, Apr 3, 2024 at 7:52 AM Evan Leibovitch via At-Large < at-large@atlarge-lists.icann.org> wrote:
Hello Haida,
On Wed, Apr 3, 2024 at 5:05 AM Hadia Abdelsalam Mokhtar EL miniawi via At-Large <at-large@atlarge-lists.icann.org> wrote:
I fully agree with you that raising users awareness and knowledge about the possibility of having domain names and email addresses in their own languages is important. I can tell you that nearly every time I participated in a session related to the DNS and/or ICANN and I raised the topic of domain names and IDNs, hardly anyone in the session was aware of the existence of Arabic domain names. How can they demand or understand the need for it when they are barely aware of its existence?
ICANN first published IDN guidelines in 2003 <https://www.icann.org/resources/pages/idn-guidelines-2003-06-20-en>. That there is so little awareness of them after more than 20 years of existence, perhaps suggests that little demand exists. That is, few people, companies or governments are asking ICANN or its community what solutions it is offering so that IDNs may be offered in response.
WhatsApp and ChatGPT support more than 50 languages, Facebook more than 100, Google Search and Twitter more than 150 each. Most chat and broadcast platforms as well as applications and operating systems enable Unicode so that anyone can use whatever script their input device can handle. Indeed platforms such as QQ and Yandex were designed primarily for use in non-Latin-script environments. In this world in which people today easily access the Internet in the language of their choice using existing methods on even the simplest of access devices, what specifically is the *public* need for IDNs? Search engines from multiple sources can take a request from anyone in their own script and language, and find the appropriate resource regardless of what its domain name happens to be. This could, indeed, work with a single domain and a flat namespace.
Our mission has two aspects: Raising awareness about the existence of IDNs and encouraging users who realize the benefits of IDNs to demand them.
What reason for confidence do you have that raising awareness of IDNs will create demand that does not yet exist? The technical and government communities within ICANN have had two decades to spread the word about IDN benefits, yet that message has not gained traction far outside the ICANN community.
Even UA Day, as an outreach effort, continues to insist on top-down efforts rather than bottom-up. From the ICANN report on last year's UA Day <https://www.icann.org/en/system/files/files/universal-acceptance-day-01jun23...>, *not a single event* anywhere in the world targeted end-users, application developers, or the mainstream news media (page 10 of the report). The "outreach" is only being done to comfortable audiences of insiders who won't ask embarrassing questions like "who actually wants this besides domain sellers?". Meanwhile, the general public of end-users -- the constituency ALAC claims to represent -- employs the many existing, easier and cheaper ways to communicate in any language with each other and with Internet content and services.
To me, IDN's current boosters remain because of (a) financial self-interest, (b) the sunk cost of decades of volunteer effort and emotions, and/or (c) their own deep lack of awareness regarding what the world has already done to solve the challenges of multilingual access.
The real awareness that I see absent is that IDNs have been met by widespread public indifference, if not rejection, despite 20 years of availability and promotion. A year's worth of more UA days is not going to change that, because simply it's an inferior solution to what has already been solved.
Cheers,
- Evan
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
-- Lance Hinds Chief Technology Officer BrainStreet Group 287 'C' Albert St. Georgetown Guyana This message contains information that may be privileged and/or confidential and is the property of BrainStreet Technologies or BrainStreet Learning. The information contained herein is intended only for the individual or entity to whom it is addressed and others authorized to receive it . If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or take any action in reliance to the contents of this information or any part thereof and it may be unlawful to do so. If you receive this message in error, please notify the sender immediately and delete all copies of this message from your system. BrainStreet Technologies or BrainStreet Learning are neither liable for the proper and complete transmission of the information contained in this communication nor any delay in its receipt.
Evan, It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs. End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved. (Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.) Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion. Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems. Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive. Bill Jouris On Wednesday, April 3, 2024 at 04:52:15 AM PDT, Evan Leibovitch via At-Large <at-large@atlarge-lists.icann.org> wrote: Hello Haida, On Wed, Apr 3, 2024 at 5:05 AM Hadia Abdelsalam Mokhtar EL miniawi via At-Large <at-large@atlarge-lists.icann.org> wrote: I fully agree with you that raising users awareness and knowledge about the possibility of having domain names and email addresses in their own languages is important. I can tell you that nearly every time I participated in a session related to the DNS and/or ICANN and I raised the topic of domain names and IDNs, hardly anyone in the session was aware of the existence of Arabic domain names. How can they demand or understand the need for it when they are barely aware of its existence? ICANN first published IDN guidelines in 2003. That there is so little awareness of them after more than 20 years of existence, perhaps suggests that little demand exists. That is, few people, companies or governments are asking ICANN or its community what solutions it is offering so that IDNs may be offered in response. WhatsApp and ChatGPT support more than 50 languages, Facebook more than 100, Google Search and Twitter more than 150 each. Most chat and broadcast platforms as well as applications and operating systems enable Unicode so that anyone can use whatever script their input device can handle. Indeed platforms such as QQ and Yandex were designed primarily for use in non-Latin-script environments. In this world in which people today easily access the Internet in the language of their choice using existing methods on even the simplest of access devices, what specifically is the public need for IDNs? Search engines from multiple sources can take a request from anyone in their own script and language, and find the appropriate resource regardless of what its domain name happens to be. This could, indeed, work with a single domain and a flat namespace. Our mission has two aspects: Raising awareness about the existence of IDNs and encouraging users who realize the benefits of IDNs to demand them. What reason for confidence do you have that raising awareness of IDNs will create demand that does not yet exist? The technical and government communities within ICANN have had two decades to spread the word about IDN benefits, yet that message has not gained traction far outside the ICANN community. Even UA Day, as an outreach effort, continues to insist on top-down efforts rather than bottom-up. From the ICANN report on last year's UA Day, not a single event anywhere in the world targeted end-users, application developers, or the mainstream news media (page 10 of the report). The "outreach" is only being done to comfortable audiences of insiders who won't ask embarrassing questions like "who actually wants this besides domain sellers?". Meanwhile, the general public of end-users -- the constituency ALAC claims to represent -- employs the many existing, easier and cheaper ways to communicate in any language with each other and with Internet content and services. To me, IDN's current boosters remain because of (a) financial self-interest, (b) the sunk cost of decades of volunteer effort and emotions, and/or (c) their own deep lack of awareness regarding what the world has already done to solve the challenges of multilingual access. The real awareness that I see absent is that IDNs have been met by widespread public indifference, if not rejection, despite 20 years of availability and promotion. A year's worth of more UA days is not going to change that, because simply it's an inferior solution to what has already been solved. Cheers, - Evan _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
Hi Bill, On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote:
It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs.
Is it really directed at apps developers? Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved.
People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and *end-user* focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on. (Except to the extend that it would be useful to show some user demand
when trying to convince vendors to become IDN compatible.)
End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that. One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and *desired*. Thus, so long as end-user demand is not seen as a *necessary* component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants. (Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.) Making end users aware of the option to use non-ASCII characters for these
is, to my mind, an entirely separate discussion.
If so, that "separate discussion" is the only one worth having within *ICANN At-Large*. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs.
Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems.
Chicken and egg. If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them. BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign.
Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive.
And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on. - Evan
Hi Evan, Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment. And I've been arguing, without apparent success, for ICANN to do exactly that. Bill Sent from Yahoo Mail on Android On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch<evanleibovitch@gmail.com> wrote: Hi Bill, On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote: It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs. Is it really directed at apps developers? Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment. End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved. People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and end-user focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on. (Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.) End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that. One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and desired. Thus, so long as end-user demand is not seen as a necessary component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants. (Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.) Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion. If so, that "separate discussion" is the only one worth having within ICANN At-Large. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs. Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems. Chicken and egg.If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them. BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign. Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive. And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on. - Evan
Hello all, if you feel strong enough about this and can convince the powers that be in our community perhaps could you suggest the ALAC makes a Statement about this? Kindest regards, Olivier On 04/04/2024 06:45, Bill Jouris via At-Large wrote:
Hi Evan,
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
And I've been arguing, without apparent success, for ICANN to do exactly that.
Bill
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>
On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch <evanleibovitch@gmail.com> wrote: Hi Bill,
On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote:
It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs.
Is it really directed at apps developers?
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved.
People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and *_end-user_* focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on.
(Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.)
End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that.
One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and _desired_. Thus, so long as end-user demand is not seen as a *necessary* component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants.
(Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.)
Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion.
If so, that "separate discussion" is the only one worth having within /ICANN At-Large/. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs.
Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems.
Chicken and egg. If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them.
BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign.
Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive.
And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on.
- Evan
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site:http://atlarge.icann.org _______________________________________________ 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.
-- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Hi Olivier, Thanks for the input. As you know I'm just a lowly ALS rep and have not been in any leadership position for quite a while. If these powers that be (all of whom I would assume are subscribed here) can be brought to consensus that IDN acceptance must be driven bottom-up and cannot succeed without research and end-user support, I'll gladly co-author a draft statement for ALAC's consideration. And you know I've written some good ones in the past ;-). - Evan On Thu, Apr 4, 2024 at 2:23 AM Olivier MJ Crépin-Leblond <ocl@gih.com> wrote:
Hello all,
if you feel strong enough about this and can convince the powers that be in our community perhaps could you suggest the ALAC makes a Statement about this? Kindest regards,
Olivier
On 04/04/2024 06:45, Bill Jouris via At-Large wrote:
Hi Evan,
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
And I've been arguing, without apparent success, for ICANN to do exactly that.
Bill
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>
On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch <evanleibovitch@gmail.com> <evanleibovitch@gmail.com> wrote: Hi Bill,
On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote:
It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs.
Is it really directed at apps developers?
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved.
People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and *end-user* focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on.
(Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.)
End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that.
One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and *desired*. Thus, so long as end-user demand is not seen as a *necessary* component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants.
(Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.)
Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion.
If so, that "separate discussion" is the only one worth having within *ICANN At-Large*. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs.
Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems.
Chicken and egg. If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them.
BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign.
Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive.
And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on.
- Evan
_______________________________________________ At-Large mailing listAt-Large@atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
-- Olivier MJ Crépin-Leblond, PhDhttp://www.gih.com/ocl.html
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Dear Evan, How about something like this? (which was pointed out to me) https://www.punycoder.com/ Kindest regards, Olivier On 04/04/2024 05:45, Bill Jouris via At-Large wrote:
Hi Evan,
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
And I've been arguing, without apparent success, for ICANN to do exactly that.
Bill
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>
On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch <evanleibovitch@gmail.com> wrote: Hi Bill,
On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote:
It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs.
Is it really directed at apps developers?
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved.
People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and *_end-user_* focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on.
(Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.)
End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that.
One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and _desired_. Thus, so long as end-user demand is not seen as a *necessary* component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants.
(Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.)
Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion.
If so, that "separate discussion" is the only one worth having within /ICANN At-Large/. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs.
Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems.
Chicken and egg. If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them.
BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign.
Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive.
And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on.
- Evan
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site:http://atlarge.icann.org _______________________________________________ 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.
Hi Olivier, That's an interesting tool, especially for debugging, but I'm not sure what role it plays in UA. With the same effort that one could use to turn their native text into punycode with that tool, one could use Google Translate (which has a very similar interface) and do more. - Evan On Mon, Apr 8, 2024 at 6:03 AM Olivier MJ Crépin-Leblond <ocl@gih.com> wrote:
Dear Evan,
How about something like this? (which was pointed out to me) https://www.punycoder.com/
Kindest regards,
Olivier
On 04/04/2024 05:45, Bill Jouris via At-Large wrote:
Hi Evan,
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
And I've been arguing, without apparent success, for ICANN to do exactly that.
Bill
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>
On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch <evanleibovitch@gmail.com> <evanleibovitch@gmail.com> wrote: Hi Bill,
On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris@yahoo.com> wrote:
It seems to me that the function of UA day is inherently NOT directed at end users. It is directed at getting vendors, those who provide software interfaces for end users, to make provision for IDNs.
Is it really directed at apps developers?
Consider that some of the apps in play are open source. ICANN could simply contribute code to Mozilla, Thunderbird, Wordpress, Signal and other projects to make their IDN support seamless. If that support is an in-demand feature it will make those applications more desirable in a competitive environment.
End users are, of course, wildly unlikely to be writing their own browsers, email systems, etc., so they don't really need to be involved.
People aren't writing browsers, email systems, etc. to satisfy the needs of ICANN, they're trying to meet the needs of end-users. So if end users don't care about IDNs, neither will apps developers, since they have other priorities such as speed, security, and *end-user* focused features such as VPNs, form auto-completion, spell-checkers, incognito modes and so on.
(Except to the extend that it would be useful to show some user demand when trying to convince vendors to become IDN compatible.)
End-user demand for IDNs isn't "useful", it's a mandatory prerequisite. Without such bottom-up demand, app developers have no incentive to divert resources. In the service of i18n developers place far more emphasis on Unicode support, multilingual UI and multilingual integrated search engines. If these features satisfy end-user needs then there is no reason for them to spend extra effort on IDNs. Developers may well see IDNs as just a way for ICANN and its contractors to peddle more domains, and without end-user interest they have no incentive to facilitate that.
One must again remind that ICANN is not a treaty-backed organization. It has no means to impose, let alone enforce, its decisions on the world. Its solutions must be superior and *desired*. Thus, so long as end-user demand is not seen as a *necessary* component in advancing IDNs, they will remain a non-priority to developers and an avoidable risk to would-be IDN registrants.
(Aside: I truly find it amazing that this argument even needs to be made within the community tasked with advancing end-user interests within ICANN.)
Making end users aware of the option to use non-ASCII characters for these is, to my mind, an entirely separate discussion.
If so, that "separate discussion" is the only one worth having within *ICANN At-Large*. Other constituencies (civil society, governments, the technical community, etc) all have their own places to define and assert their own needs.
Both whether it is a worthwhile effort and how to go about it if so. It is also something that would really need to be deferred until something like Universal Acceptance is available on at least the most widespread browsers and email systems.
Chicken and egg. If end-users don't care about IDNs, browsers and apps won't support them. If browsers and apps don't support IDNs, end-users won't care about them.
BTW, the objective is not for browsers to implement "UA". Support for IDNs is the solution being pitched, UA is just the name of the marketing campaign.
Pitching to end users, when the software they use does not yet support IDNs, would be counterproductive.
And THAT is why, 20 years from now, ICANN will still be wondering why IDNs never caught on.
- Evan
_______________________________________________ At-Large mailing listAt-Large@atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
participants (15)
-
Alfredo Calderon -
Andrey Kolesnikov -
Anivar Aravind -
Barrack Otieno -
Bill Jouris -
Carlton Samuels -
Evan Leibovitch -
Hadia Abdelsalam Mokhtar EL miniawi -
Jonathan Zuck -
Karl Auerbach -
Lance Hinds -
Natalia Filina -
Olivier MJ Crépin-Leblond -
Roberto Gaetano -
Satish Babu