Harsha: Thank you for following up on our discussion in the meeting. I like it when people use the email lists for this. We can get more done if we continue discussions between meetings. That said, On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote:

As agreed at the meeting on the 2nd of August, I went through the RFC 6532 and checked whether header fields inherit the text encoding (UTF-8) from an Operating System of a device. Having tested with multiple devices with different OSs, It looks that header fields inherit from the Operating System for Sinhala. RFC 6532 and other relevant RFCs state as either System or Systems where encoding is inherited.…

I'm sorry, I don't follow you. If I were to summaries RFC 6532 <https://datatracker.ietf.org/doc/rfc6532/>, it would be "You can use UTF-8 in email headers". I don't see RFC 6532 talking about inheriting anything. Nor about permitting any additional encoding apart from UTF-8. Nor about getting information about encoding from systems. Would you mind giving references to specific sections of RFC 6532, and/or give examples of what headers are interesting for Sinhala?

Therefore, IETF should clarify the above with more elaboration.

What sections of RFC 6532 would you have IETF change, and how? I do not know Sinhala at all, so any explanations I can get will help me learn more. Best regards,     —Jim DeLaHunt On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote:

Dear Mark, Jim, and Seda, As agreed at the meeting on the 2nd of August, I went through the RFC 6532 and checked whether header fields inherit the text encoding (UTF-8) from an Operating System of a device. Having tested with multiple devices with different OSs, It looks that header fields inherit from the Operating System for Sinhala. RFC 6532 and other relevant RFCs state as either System or Systems where encoding is inherited. Therefore, IETF should clarify the above with more elaboration. Thanks and regards Harsha Wijayawardhana

On Tue, Aug 9, 2022 at 7:56 PM Seda Akbulut via UA-EAI <ua-eai@icann.org> wrote:

Dear EAI WG members,

Enclosed please find the meeting notes for the last meeting (02 Aug 2022).

Looking forward to meeting today (9 Aug) at 14:30 UTC.

Best regards,

Seda Akbulut

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

-- . --Jim DeLaHunt,jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada Canada mobile +1-604-376-8953

Hello Harsha, others, If you want to use RFC 6532 email directly in a Windows 10 command prompt window, I'd recommend you try switch the encoding of the window to UTF-8. I think the command to do that is `chcp 65001`. RFC 6532, like most RFCs, deal with how the data is transferred "over the wire", not with the display to the user, which is left to individual implementations and environments. Regards, Martin. On 2022-08-17 10:48, harsha wijayawardhana via UA-EAI wrote:

Dear Jim,

Thank you for the email. It seems my email requires further elaboration, and I had been vague, it looks. If you remember, our conversation at the meeting had been about encoding header fields. RFC 6532 covers the following as mentioned in the abstract:

" However, full internationalization of electronic mail requires additional

enhancements to allow the use of Unicode, including characters

outside the ASCII repertoire, in mail addresses as well as direct use

of Unicode in header fields like "From:", "To:", and "Subject:",

without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows the use of Unicode in mail addresses and most header field content."

Encoding can be done by mail application without intervention from OS. The second part of the problem we discussed was how to visually show U-label. It is also mentioned in RFC 6532 very clearly that those encoded strings must be user-visible. Let me quote the Introduction of the RFC 6532:

" Internet mail header field values contain a variety of strings that are

intended to be user-visible."

To make it user-visible either the application or the OS must have a relevant font and the rendering engine. At that meeting, several questions came about encoding and user visibility of those encoded strings. I also mentioned, that in the terminal window of Windows 10, when using network tools such as PING, TRACERT squares appear for U-Label, and domain names of Non-ASCII do not resolve either.

I checked all relevant RFCs related to RFC 6532. Relevant RFCs speak of Systems encoding strings, but they do not specify how it is carried out clearly. I quote from RFC 6532 again:

"And finally, native support for the UTF-8 charset is now available on most systems. Hence, it is strongly desirable for Internet mail to support UTF-8 [RFC3629 <https://www.rfc-editor.org/rfc/rfc3629>] directly."

Having gone through almost all these relevant RFCs, I checked by sending an email with UTF-8 headers to several devices with different Operating Systems. Android, and Apple IOS, both recognized the encoding but also showed Sinhala without any issue. All Operating Systems are now native to Unicode. Though Operating Systems have support for Unicode, some applications still show squares without inheriting rendering from the Operating System.

Having observed and identified the default font these mail applications used to display the Sinhala String of header fields, I concluded that these mail clients/ applications use rendering and UTF-8 support from the OS. However, as I pointed out, the terminal windows of Windows 10 have issues resolving U-labels.

Since it is still confusing what is meant by "System" or "Systems" in most RFCs and my view is that RFCs must further elaborate on encoding and user-visibility whether it uses OSs' or Mail Applications' encoding.

Thanks and Best Regards

Harsha

On Wed, Aug 17, 2022 at 5:36 AM Jim DeLaHunt via UA-EAI <ua-eai@icann.org> wrote:

...

Harsha:

Thank you for following up on our discussion in the meeting. I like it when people use the email lists for this. We can get more done if we continue discussions between meetings.

That said, On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote:

As agreed at the meeting on the 2nd of August, I went through the RFC 6532 and checked whether header fields inherit the text encoding (UTF-8) from an Operating System of a device. Having tested with multiple devices with different OSs, It looks that header fields inherit from the Operating System for Sinhala. RFC 6532 and other relevant RFCs state as either System or Systems where encoding is inherited.…

I'm sorry, I don't follow you.

If I were to summaries RFC 6532 <https://datatracker.ietf.org/doc/rfc6532/> <https://datatracker.ietf.org/doc/rfc6532/>, it would be "You can use UTF-8 in email headers". I don't see RFC 6532 talking about inheriting anything. Nor about permitting any additional encoding apart from UTF-8. Nor about getting information about encoding from systems.

Would you mind giving references to specific sections of RFC 6532, and/or give examples of what headers are interesting for Sinhala?

Therefore, IETF should clarify the above with more elaboration.

What sections of RFC 6532 would you have IETF change, and how?

I do not know Sinhala at all, so any explanations I can get will help me learn more.

Best regards, —Jim DeLaHunt On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote:

Dear Mark, Jim, and Seda, As agreed at the meeting on the 2nd of August, I went through the RFC 6532 and checked whether header fields inherit the text encoding (UTF-8) from an Operating System of a device. Having tested with multiple devices with different OSs, It looks that header fields inherit from the Operating System for Sinhala. RFC 6532 and other relevant RFCs state as either System or Systems where encoding is inherited. Therefore, IETF should clarify the above with more elaboration. Thanks and regards Harsha Wijayawardhana

On Tue, Aug 9, 2022 at 7:56 PM Seda Akbulut via UA-EAI <ua-eai@icann.org> wrote:

...

Dear EAI WG members,

Enclosed please find the meeting notes for the last meeting (02 Aug 2022).

Looking forward to meeting today (9 Aug) at 14:30 UTC.

Best regards,

Seda Akbulut

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

_______________________________________________ UA-EAI mailing listUA-EAI@icann.orghttps://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

-- . --Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant

2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada Canada mobile +1-604-376-8953

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

On 8/17/2022 12:39 AM, harsha wijayawardhana via UA-EAI wrote:

Dear Martin, I did that also, but it did not work. I'm now getting squares with question marks. I think I need to download powershell. Let me do that and give feedback.

You would need to set the console to use a font that can support the code points you are displaying. 仠 gives a square with a question mark if I set the console to "Consolas" but shows as expected if I select a CJK font. A./ (PS: the console does not appear to have the kind of font fallbacks that we've come to expect from browsers).

Thanks and BR, Harsha

On Wed, Aug 17, 2022 at 11:41 AM Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:

Hello Harsha, others,

If you want to use RFC 6532 email directly in a Windows 10 command prompt window, I'd recommend you try switch the encoding of the window to UTF-8. I think the command to do that is `chcp 65001`.

RFC 6532, like most RFCs, deal with how the data is transferred "over the wire", not with the display to the user, which is left to individual implementations and environments.

Regards,   Martin.

On 2022-08-17 10:48, harsha wijayawardhana via UA-EAI wrote: > Dear Jim, > > Thank you for the email. It seems my email requires further elaboration, > and I had been vague, it looks. If you remember, our conversation at the > meeting had been about encoding header fields. RFC 6532 covers the > following as mentioned in the abstract: > > " However, full internationalization of electronic mail requires additional > >     enhancements to allow the use of Unicode, including characters > >     outside the ASCII repertoire, in mail addresses as well as direct use > >     of Unicode in header fields like "From:", "To:", and "Subject:", > >     without requiring the use of complex encoded-word constructs. This > document specifies an enhancement to the Internet Message Format and to > MIME that allows the use of Unicode in mail addresses and most header field > content." > > > Encoding can be done by mail application without intervention from OS. The > second part of the problem we discussed was how to visually show U-label. > It is also mentioned in RFC 6532 very clearly that those encoded strings > must be user-visible. Let me quote the Introduction of the RFC 6532: > > " Internet mail header field values contain a variety of strings that are > >     intended to be user-visible." > > To make it user-visible either the application or the OS must have a > relevant font and the rendering engine. At that meeting, several questions > came about encoding and user visibility of those encoded strings. I also > mentioned, that in the terminal window of Windows 10, when using network > tools such as PING, TRACERT squares appear for U-Label, and domain names of > Non-ASCII do not resolve either. > > I checked all relevant RFCs related to RFC 6532. Relevant RFCs speak of > Systems encoding strings, but they do not specify how it is carried out > clearly. I quote from RFC 6532 again: > > "And finally, native support for the UTF-8 charset is now available on most > systems. Hence, it is strongly desirable for Internet mail to support UTF-8 > [RFC3629 <https://www.rfc-editor.org/rfc/rfc3629>] directly." > > Having gone through almost all these relevant RFCs, I checked by sending an > email with UTF-8 headers to several devices with different Operating > Systems. Android, and Apple IOS, both recognized the encoding but also > showed Sinhala without any issue. All Operating Systems are now native to > Unicode. Though Operating Systems have support for Unicode, some > applications still show squares without inheriting rendering from the > Operating System. > > Having observed and identified the default font these mail applications > used to display the Sinhala String of header fields, I concluded that these > mail clients/ applications use rendering and UTF-8 support from the OS. > However, as I pointed out, the terminal windows of Windows 10 have issues > resolving U-labels. > > Since it is still confusing what is meant by "System" or "Systems" in most > RFCs and my view is that RFCs must further elaborate on encoding and > user-visibility whether it uses OSs' or Mail Applications' encoding. > > > Thanks and Best Regards > > Harsha > > > > > > > On Wed, Aug 17, 2022 at 5:36 AM Jim DeLaHunt via UA-EAI <ua-eai@icann.org> > wrote: > >> Harsha: >> >> Thank you for following up on our discussion in the meeting. I like it >> when people use the email lists for this. We can get more done if we >> continue discussions between meetings. >> >> That said, >> On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote: >> >> As agreed at the meeting on the 2nd of August, I went through the RFC 6532 >> and checked whether header fields inherit the text encoding (UTF-8) from an >> Operating System of a device. Having tested with multiple devices with >> different OSs, It looks that header fields inherit from the Operating >> System for Sinhala. >> RFC 6532 and other relevant RFCs state as either System or Systems where >> encoding is inherited.… >> >> I'm sorry, I don't follow you. >> >> If I were to summaries RFC 6532 >> <https://datatracker.ietf.org/doc/rfc6532/> >> <https://datatracker.ietf.org/doc/rfc6532/>, it would be "You can use >> UTF-8 in email headers". I don't see RFC 6532 talking about inheriting >> anything. Nor about permitting any additional encoding apart from UTF-8. >> Nor about getting information about encoding from systems. >> >> Would you mind giving references to specific sections of RFC 6532, and/or >> give examples of what headers are interesting for Sinhala? >> >> Therefore, IETF should clarify the above with more elaboration. >> >> What sections of RFC 6532 would you have IETF change, and how? >> >> I do not know Sinhala at all, so any explanations I can get will help me >> learn more. >> >> Best regards, >>      —Jim DeLaHunt >> On 2022-08-16 01:25, harsha wijayawardhana via UA-EAI wrote: >> >> Dear Mark, Jim, and Seda, >> As agreed at the meeting on the 2nd of August, I went through the RFC 6532 >> and checked whether header fields inherit the text encoding (UTF-8) from an >> Operating System of a device. Having tested with multiple devices with >> different OSs, It looks that header fields inherit from the Operating >> System for Sinhala. >> RFC 6532 and other relevant RFCs state as either System or Systems where >> encoding is inherited. Therefore, IETF should clarify the above with more >> elaboration. >> Thanks and regards >> Harsha Wijayawardhana >> >> On Tue, Aug 9, 2022 at 7:56 PM Seda Akbulut via UA-EAI <ua-eai@icann.org> >> wrote: >> >>> Dear EAI WG members, >>> >>> >>> >>> Enclosed please find the meeting notes for the last meeting (02 Aug 2022). >>> >>> >>> >>> Looking forward to meeting today (9 Aug) at 14:30 UTC. >>> >>> >>> >>> Best regards, >>> >>> Seda Akbulut >>> >>> >>> _______________________________________________ >>> UA-EAI mailing list >>> UA-EAI@icann.org >>> https://mm.icann.org/mailman/listinfo/ua-eai >>> _______________________________________________ >>> 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. >>> >> >> _______________________________________________ >> UA-EAI mailing listUA-EAI@icann.orghttps://mm.icann.org/mailman/listinfo/ua-eai <http://mm.icann.org/mailman/listinfo/ua-eai> >> _______________________________________________ >> 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. >> >> -- >> .   --Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) >>        multilingual websites consultant >> >>        2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada >>           Canada mobile +1-604-376-8953 >> >> _______________________________________________ >> UA-EAI mailing list >> UA-EAI@icann.org >> https://mm.icann.org/mailman/listinfo/ua-eai >> _______________________________________________ >> 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. > > > _______________________________________________ > UA-EAI mailing list > UA-EAI@icann.org > https://mm.icann.org/mailman/listinfo/ua-eai > _______________________________________________ > 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.

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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 Martin, Let me check and come back normally it has required fonts. Harsha On Wed, 17 Aug 2022, 14:37 Martin J. Dürst via UA-EAI, <ua-eai@icann.org> wrote:

Hello everybody,

`chcp 65001` worked for me to display an UTF-8 file with Japanese text. I guess that's because the console was already set to a Japanese font. I assume that it should work for Harsha with some Sinhala text in UTF-8, because the console should already have as suitable font.

Regards, Martin.

On 2022-08-17 17:46, Asmus Freytag via UA-EAI wrote:

...

On 8/17/2022 12:39 AM, harsha wijayawardhana via UA-EAI wrote:

...

Dear Martin, I did that also, but it did not work. I'm now getting squares with question marks. I think I need to download powershell. Let me do that and give feedback.

You would need to set the console to use a font that can support the code points you are displaying.

仠 gives a square with a question mark if I set the console to "Consolas" but shows as expected if I select a CJK font.

A./

(PS: the console does not appear to have the kind of font fallbacks that we've come to expect from browsers).

...

Thanks and BR, Harsha

---

UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.

+PC for visibility. I don't think there are any Unicode issues impacting us. We already specify UTF-8 and IDNA2008, and we already expect software providers to provide mitigations for homoglyphs ... From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Asmus Freytag via UA-EAI Sent: Wednesday, August 17, 2022 2:06 AM To: ua-eai@icann.org Subject: [EXTERNAL] [UA-EAI] Input requested: Suggested EAI related additions to Unicode FAQ? All, the Unicode Consortium maintains FAQs on a number of topics, both relating to aspects of the standard, but also common issues around its usage. There's currently an effort underway to review and update many of these FAQs. The group maintaining them suggested I contact this list to inquire whether there are any unicode-related issues concerning EAIs in particular or UA topics in general which might usefully be added. One likely page, which also shows the format is accessible here (latest draft): https://corp.unicode.org/~asmus/proposed_faq/unicode_web.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcorp.unicode.org%2F~asmus%2Fproposed_faq%2Funicode_web.html&data=05%7C01%7Cmarksv%40microsoft.com%7C25b7adae421340c4bfed08da802fce4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637963240066697352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fK8i%2ByJj1pFCsVW6WCWfkZjKogCTR2w%2FgH9XZZR8Tx0%3D&reserved=0> This page used to contain a number of questions and answers around using Unicode with Email which were removed as outdated, without a clear consensus about what kind of information might be of current relevance. The full set of FAQs (released version) is available here: https://www.unicode.org/faq/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.unicode.org%2Ffaq%2F&data=05%7C01%7Cmarksv%40microsoft.com%7C25b7adae421340c4bfed08da802fce4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637963240066697352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HWUGTsg1XyW4vS%2FVXzraF4uDHHld2uGRQq4g2RYkU5g%3D&reserved=0> Suggestions for corrections, additions and other updates may be directed to me or submitted to the suggestion form as explained in the link just above. Specific input, providing (or indicating) the question and given a reply (or replacement text) would be highly appreciated, even if the feedback reflects expertise in some other subject. If adopted, questions and answers may be placed in any file that seems the most appropriate under the circumstances. A./ PS: if this is not the correct list, or if other lists should be notified, please feel free to pass this on.

I agree that this is a challenge of the scoring system effort. If a user experience if broken due to i18n/l10n issues unrelated to 6530-6532, what should we say about it? Our consensus has been that if the brokenness is a result of choices by the provider, then it gets a score demerit. If it's entirely a result of things outside the control of the provider, then it shouldn't be included in the guide at all. So it's important to determine whether something is inherited from the platform (for example), since that is outside of the provider's control. -----Original Message----- From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Arnt Gulbrandsen via UA-EAI Sent: Wednesday, August 17, 2022 4:20 AM To: ua-eai@icann.org Subject: [EXTERNAL] Re: [UA-EAI] header fields inherit from the Operating System for Sinhala [was: Re: UA EAI Meeting Notes 02 August 2022] Hi, I think there's a misunderstanding with regard to RFC 6532. An email message may be said to require three things. 1. That the sender composes it. 2. Transmission from sender to recipient. 3. That the recipient reads it. IETF standards concern themselves exclusively with point 2. If the recipient lacks the necessary fonts to display the message (or the sender does!), that doesn't affect RFC 6532's concept of validity, because that validity exists only within point 2. As a consequence of that, if the message is 6532-valid, then the receiving software has to understand which characters it should display (or read). Successful display is outside the bounds of 6532, but understandable communication of what is to be displayed is within. Arnt _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fua-eai&data=05%7C01%7Cmarksv%40microsoft.com%7C6a85395b1d1b4e34764c08da804e3d24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637963370776306273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FuBPISWvWwiEOZ5hT6q1h2AHfqCRm00YSUWJQiYQrqc%3D&reserved=0 _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=05%7C01%7Cmarksv%40microsoft.com%7C6a85395b1d1b4e34764c08da804e3d24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637963370776306273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6ZOKMWXWlLuFEGdF%2BFKaLcZS%2B9VIqdgTsxyEI27NW5g%3D&reserved=0) and the website Terms of Service (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=05%7C01%7Cmarksv%40microsoft.com%7C6a85395b1d1b4e34764c08da804e3d24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637963370776462496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sTWk2I73gxVGyr2iZiiE2l68HMOZ2qC6A3U4MnpvX4o%3D&reserved=0). 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 Mark, Arnt, and Jim, I also agree with Mark and you, Arnt. I have to give you a status report on how Sinhala is fairing on the Internet. As I said earlier, Sinhala renders very well on Social Media (except for Facebook, where Rakar, Yansa, and Reph forms break) and on the Web. Emails in Sinhala worked well when I checked by sending Sinhala emails between two senders and receivers through Gmail using multiple digital devices. Sinhala in the email subject field and body renders beautifully. As I said earlier, text content on the header fields worked fine, and I can send the Print Screens as proof. What I was trying to check was whether UTF-8 content of header fields inherits or uses UTF-8 encoding from OS or Mail applications. As I mentioned in my previous email, I understood that RFC 6532 talks about net-UTF-8, and it talks about the User visibility of UTF-8 content in the Header fields of an email. The second issue I raised has nothing to do with RFC 6532. It is important that network tools such as PING, and TRACERT work in the window's shell or command line. It does not have to be Windows 10, but it can be a shell of any operating system. I realized the importance since I'm in the process of setting up Email Servers to send and receive Sinhala ccTLD Domain, etc. As I said, in the Windows 10 console, Sinhala does not render at all due to the lack of Sinhala font. To install a Sinhala font, I have to go to Windows Registry and make an entry. I'm in the process of doing it now and will revert to you the outcome. However, I found several issues with Thunderbird and MS Outlook mail clients trying to create an email account. ICANN had also reported the same in your UA readiness report when I checked last night, which you shared at yesterday's meeting. I hope that this will provide the exact status of Sinhala on the Internet. Let us have further discussion on this topic. Thank you and Best Regards Harsha On Wed, Aug 17, 2022 at 8:42 PM Arnt Gulbrandsen via UA-EAI < ua-eai@icann.org> wrote:

Very good point.

My instinctive opinion is to make it simple, and limit testing/scoring to end-user systems that are able to display all of the text on e.g. https://en.wikipedia.org/wiki/Sinhala_language

If a mail system can't display Sinhala mail on an end-user system that can display that web page, then we count it as a demerit. If it can't on a system that can't, we disregard that, because something that can't display Wikipedia is just too broken to care about.

Arnt _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ 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.