Hi Mark,--On November 15, 2006 1:23:10 PM -0800 Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx> wrote:
- In Section 1 it states that the server SHOULD support COMPARATOR if the SORT extension is defined, but it does not explicitly state the same for the THREAD extension. Since THREAD uses SEARCH and has a subject matching step, I think it should also say SHOULD support COMPARATOR.Would it be alright if this was simply generalized to "SORT and/or THREAD extension"?
Yes.
- In Section 2.1 it states that the 'base subject' algorithm must be used when 'sorting by subject'. It does not explicitly state that it also needs to be used when doing THREAD=ORDEREDSUBJECT and THREAD=REFERENCES - it should.Would it be alright if this was generalized to "sorting or threading by subject" (without having to specifically list threading algorithms)?
Yes.
- Currently the (expired) COMPARATOR extension states it applies to THREAD=ORDEREDSUBJECT but not THREAD=REFERENCES. Yet the later includes a base subject comparison step, so COMPARATOR should be used for that too.This is an issue in the COMPARATOR document, isn't it?
Yes - sorry should have stipulated that.
- Its not clear in either SORT/THREAD or COMPARATOR how the active comparator affects the base subject matching.Could you elaborate on what you mean by this? I was under the impression that it was clear that base subjects are compared the way anything else is compared.- Its not clear whether there will be a use case for different comparators for the different steps in SORT/THREAD. e.g. would someone want to use a case-sensitive comparator for the SEARCH portion, and then a case-insensitive one for sort collation? What about having the active comparator affect the base subject comparison too?I hope not. This strikes me as being horrible over-engineering.
These two issues are being discussed in the 'LANGUAGE/COMPARATOR review' thread. I think its an issue for the i18n draft not sort.
-- Cyrus Daboo