On 5.9.2007, at 16.23, Dave Cridland wrote:
On Wed Sep 5 13:34:35 2007, Dan Karp wrote:> > > Well, given that you have to implement "i;octet" anyway for > > > > "i;unicode-casemap", I'm not sure it makes any real difference > > > > whether we mandate it or not.> > > > That's not the case. It certainly isn't so in my case...> > Well, you don't have to expose it, but you do need to implement all > of its operations.Again, I'm pretty sure that's not so.I'm not sure how one could implement it without implementing all of "i;octet", given such things as:Following the above preparation process on each string, the equality,ordering and substring operations are as for i;octet. And: (b) If the input string is in an unknown charset, or aninvalid sequence occurs in step (1)(a), conversion ceases.No further preparation is performed, and any partialpreparation results are discarded. The original string isused unchanged with the i;octet comparator.
This is for the message data, which isn't a problem. The problem is i;octet would allow searching with any kind of search keys. For example "ä" in UTF-8 is 0xC3 0xA4. With i;octet it would be possible to search for only 0xA4 and it would have to match UTF-8 "ä" letters. Full text search indexing for IMAP already has to deal with substring matching, requiring it to deal with octet matching also would make it even more bloaty for no real advantage.
Description: This is a digitally signed message part