Hi. First a status report. Rather than wait until the last minute, I went ahead and pasted a template description into the BOF wiki page. The entry there is a slightly shortened and rewritten version of my initial note in this thread. https://trac.tools.ietf.org/bof/trac/wiki/WikiStart I've listed Patrik (without asking him) and myself as "proponents" for this, but would be happy to add names (or have others do so). Spencer, I assumed it would be not be appropriate to add you there, but you'd certainly be welcome if I got that wrong. Because I had to choose and because most of the i18n-specific WGs have been in Apps/ART, I've put it into that area, but I believe that IESG needs to figure out how to handle this. I could make a case for General (on the theory that many areas are covered or that procedural changes might be needed) or for Security (because the most recent major i18n interactions that I know about have been with a WG there), but, again, the IESG should decide. -------- Now a few comments on recent postings (after I went to work on the template). * I think it would be a just dandy idea to require an "I18N Considerations" section in every I-D or RFC. I see only two problems with it. One is that we've had such a requirement for documents that do have i18n issues for 20+ years and it hasn't helped. We've also had suggestions for including a statement about i18n issues in Shepherd templates. If the IESG were to decide to enforce that requirement by changing the I-D checker and refusing to consider any document that doesn't have at least a clear "no issues" statement, we might make some progress, but no one has yet convinced them it would be appropriate (that has been tried several times, but mostly in individual or directorate discussions). The other is that, while I rather like the idea of some sort of formal process or review by experts, we explored that some years ago too. It requires committed experts and the difficulty in finding those is part of the problem, not an obvious solution. Speaking as a likely stuckee, if the idea doesn't have a clear structure and a commitment from the IESG and the community will be taken seriously rather than as miscellaneous review input (i.e., more like MIB Doctors input in their area of expertise rather than notes from whomever drew the short straw, regardless of expertise, on the Foo Area Review Team), staffing that effort and keeping it staffed is likely a non-starter. So, even if we are agreed that a required I-D/ RFC section would solve the problem, we would still benefit from this BOF to start shorting out those details. * Neils, having spend months, probably years, of my life trying to explain to assorted well-intentioned people in social justice, human rights, and getting more people on the Internet in a way that is fair and appropriate to their cultures spaces why these are hard problems and that superficial solutions make things worse, no, making this a human rights issue wouldn't help. I'm sorry to single out the documents to which you pointed for special consideration, but RFC 8280 is an example of a document that should have gotten serious i18n review and apparently didn't. The second question in Section 6.2.5 should have set off alarms because character coding is only a tiny part of the issues and not even the most important part. Yes, support for multiple "charsets" is a bad idea, but, because the mappings from other CCSs and back are usually (but not always) completely deterministic and reversible, a far less serious one than a long series of other issues. For a web-oriented illustration of another set of important problems, I suggest that you have a look at https://w3c.github.io/typography/gap-analysis/language-matrix.html .. I'm also very concerned that the last paragraph of that section seems to argue for relaxing the "protocol identifier" constrain while showing no evidence of understanding it beyond what might be described as "multlingualism good". If the Human Rights Review Team were to start complaining about the absence of Internationalization Consideration sections, I think that would be positive, but the expertise needed to adequate consider Human Rights issues and that needed to consider i18n ones is very different and RFC 8280 may actually be proof of that. * Crypto expert mindsets -- I agree with John Levine on this. FWIW, a few of us have made the observation that this i18n area is easy to learn about for one class of people. Not impossible for others, but seemingly hard to grasp. That class of people consists of those who had strong exposure to at least three languages, using at least two scripts (ideally ones that are not closely related, i.e., Greek, Latin, and Cyrillic may only count as one... or not), before the age of about seven (connected to the Chomsky hypothesis about roughly the point that most people can no longer acquire languages and language intuition as a child). As Peter points out, "competence" is easier, but one still has to get fairly deep into the characteristics of several unrelated (at least in the last three or four thousand years or so) writing systems to reach that point. And even that ignores issues with spoken language, which much of the linguistics community would claim is the only thing that is important. * Mentions of UTR#46 in general I18N contexts may be close to mentioning Hitler under Godwin's Law. It is strictly about IDNs and not the general problem; its current version makes assumptions equivalent to domain names not needing to be treated as having important properties of identifiers; etc. As I said, I don't think this BOF effort is about particular protocol issues. However, as a non-protocol issue (and maybe the point John Levine was trying to make) due in no small measure to UTR#46 and the homebrew updates to IDNA2003 it has encouraged, we have a large number (perhaps dozens) of interpretations about what IDNA is "really" about and what the requirements "really" are. That is an operational and user predictability problem, a security problem, etc. "No urgency"? Only if one wants to see the IDN situation deteriorate to the point that systems that are concerned about privacy, malware, etc., will simply filter out all of them as a good tradeoff against the risks. And, again, I see IDNs as one issue here among many, not the only or even the key issue. john
