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/