Re: [I18nrp] Additional input needed for i18nRP BOF

[Larry Masinter <[e-mail]>]

I’m trying to address what I think is a ‘process’ question:

Dealing with unintentional confusables is not something that ‘more specifications’ can address, because what makes something confusable depends on too many factors that are transient, because the people who want a name with a problem they might not be aware of won’t care about the other 99% of bad cases, they just want THEIR name. 

 

Procedurally:

 

*	Stop trying to make standards-track documents about how to normalize names. 
*	Widely available services or tools for avoiding confusable names would be handy, but they can err on the side of caution. 
*	 An informational document might be useful, perhaps starting with insightful emails on the list.

 

Dealing with malicious confusables is mainly a security issue. You don’t need to know any of the details of whether something is or isn’t confusable except to acknowledge that the there is no complete agreement on how to compare Unicode strings and agreement is unlikely in the foreseeable future. 

 

Procedurally:

 

*	Introduction of confusables is part of the attack surface that the “Security Considerations” of any protocol with i18n elements must address. No separate I18N-considerations necessary.
*	Document how current services deal with confusables and mitigate the problems (phishing, domain name poaching, etc.) in a BCP if you can get some agreement on which Current Practices are Best.

 

I’m trying to address process by suggesting things that IETF might be able to make progress on without new acquisition of expertise. 

 

Larry

 

From: Adam Roach [mailto:[e-mail]] 
Sent: Friday, June 8, 2018 12:34 PM
...

 

Thanks, Larry. It's good to hear from you.

This seems like sound advice. I'll point out that we're trying to determine a *process* for addressing i18n issues rather than addressing the actual issues right now.