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] 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 be further elaborated on encoding and user-visibility whether it uses OSs' or Mail Applications' encoding.
Thanks and Best Regards
Harsha
_______________________________________________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
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.