Mark Crispin writes:
On Tue, 21 Nov 2006, Cyrus Daboo wrote:OK - so it sounds like we may want both of these. If so, it seems like separate drafts would be better.Mark, are you in a position to write a draft for i;unicode-casemap? Or would you like someone else to?I am willing to write a draft for i;unicode-casemap, but I think that it belongs in the same document as i;ascii-casemap.
I disagree and it may not be possible anyway.Disagreement: That document defines a registry and registers the preexisting collations (those from RFC 2244). That's a fine scope for a document, and I'd rather not extend it beyond its natural boundary. But I don't think opinions matter, because:
Possibility: I've already sent that document to the RFC editor, six weeks ago I think. It sounds like a very long stretch to add a whole new section as an RFC Editor's Note, particularly if that section is outside the document's scope as I explained it to the IESG.
Also, as i;unicode-casemap is intended to be a better default for an IMAP server than i;ascii-casemap, should we stipulate that a server should implement one or the other but not both? Is there any reason why either i;unicode-casemap or i;ascii-casemap would be used by any implementation that supports i;basic?
Speed. I'm not being facetious. There are cases where string equality testing is a big performance bottleneck, enough that it's bothersome. In my GUI-programming past I've had to optimize such things before in order to get a decent UI feel. I could implement i;unicode-casemap fast enough that on modern CPUs it outruns RAM/L3 cache. A really good programmer might be able to optimise i;basic that well, but I don't know how, and even it so, I don't think we should rely on people being much smarter than I am.
It would be a pity if we require i;basic use in cases where it's not really needed, just because we don't have something more appropriate at hand.
Arnt