Re: [idn] WG last call summary

["Eric A. Hall" <ehall@ehsco.com>]

Dave Crocker wrote:

> The reference to searching nicely underscores that this entire thread
> pertains to local implementation issues,

"Searching" in the context of RFC2047 doesn't just apply to local issues.
Consider that IMAP SEARCH and NNTP XPAT both provide protocol mechanisms
to search server-based data. However, I don't know of any clients that
convert "ë" to "=EB" for those searches.

That's partly a local issue, but it is also a protocol issue, and in the
end it is also a service-wide issue. At some point, somebody has to say
"okay we either mandate back-end conversion to allow for unencoded
searches or we mandate encoded search behavior." Globally, it is a
user-interaction issue, where the facade failed, due to the lack of direct
integration.

This same kind of issue will apply equally to searches for an "ë" that is
embedded into a domain name component of an email address, and which has
been ACE-encoded. There are multiple secondary considerations here as
well. Searching for a single "ë" that has been encoded with ACE is not as
simple as searching for an "=EB" sequence with 2047, for example. I dare
say that substring searches are likely to prove impossible with
ACE-encoded strings.

Anyway, clearly these aren't just local implementation issues.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/