Re: **1 WEEK** WGLC on draft-ietf-imapext-i18n-12.txt

[Timo Sirainen <tss@xxxxxx>]

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 an
>               invalid sequence occurs in step (1)(a), conversion  
> ceases.
>               No further preparation is performed, and any partial
>               preparation results are discarded.  The original  
> string is
>               used 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.

Attachment: PGP.sig
Description: This is a digitally signed message part