Arnt Gulbrandsen | 2 May 21:05 2006
Picon

SEARCH and COMPARATOR


Hi,

now that Timo Sirainen shot down my GIF87 example (for which I am 
grateful, even as I am feeling less than grateful), could someone dream 
up a reason to use two different collations at the same time, or at 
least nearly at the same time? Ideally a search.

I am resolving the SEARCH issue by fiat: "COMPARATOR collation-name 
search-key", applying that collation to that search-key (which may use 
ordinary IMAP and/or/blah).

Arnt

Dave Cridland | 2 May 21:22 2006
Picon

Re: SEARCH and COMPARATOR


On Tue May  2 20:05:07 2006, Arnt Gulbrandsen wrote:
> I am resolving the SEARCH issue by fiat: "COMPARATOR collation-name 
> search-key", applying that collation to that search-key (which may 
> use ordinary IMAP and/or/blah).
> 
> 
My inclination is that this might be better dealt with in more 
drastic ways, and we should actually forget about it for now. 
Specifically, I think IMAP ought to admit that Sieve has much more 
interesting tests, for the most part, and even provides ANDs and 
exciting stuff. This is not to suggest that you need write all that 
in, it's more to suggest that it's not worth tackling that problem 
there.

Good enough for me would be a comparator option for SEARCH changing 
the default comparator for that SEARCH command only.

Dave.
--

-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Arnt Gulbrandsen | 9 May 22:14 2006
Picon

draft-newman-i18n-collation-09.txt just posted


As far as I know, this addresses, ignores or adds open issues for all 
requests. If something is ignored, that's because other people wanted 
the opposite, or because I overlooked it when I went over all the mail 
this week. I'm sorry about it in either case.

Review, please.

Arnt

John Cowan | 9 May 22:45 2006

Re: draft-newman-i18n-collation-09.txt just posted


Arnt Gulbrandsen scripsit:

> As far as I know, this addresses, ignores or adds open issues for all 
> requests. If something is ignored, that's because other people wanted 
> the opposite, or because I overlooked it when I went over all the mail 
> this week. I'm sorry about it in either case.
> 
> Review, please.

Posted where?  Neither rfc-editor.org nor ietf.org seems to have it.

--

-- 
John Cowan  cowan <at> ccil.org  http://ccil.org/~cowan
The penguin geeks is happy / As under the waves they lark
The closed-source geeks ain't happy / They sad cause they in the dark
But geeks in the dark is lucky / They in for a worser treat
One day when the Borg go belly-up / Guess who wind up on the street.

Mark Davis | 10 May 00:43 2006

Re: draft-newman-i18n-collation-09.txt just posted


The release of this is timely (we didn't get notified of a 07 or 08 
draft), since the Unicode Technical Committee is meeting next week, and 
can discuss it.

Could you indicate which of the items raised in the email of 2006-02-21 
from the Unicode Technical Committee have been addressed in this release 
(and if not accepted then why)? That would help greatly with the review. 
(I couldn't find any archive for discussion of 
draft-newman-i18n-comparator where that email could be publicly linked 
from, so I am appending it at the end of this message.) At a quick 
glance, it appears that a number of comments have been incorporated.

Mark

BTW, despite the subject of the message, the document is at 
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt. 
It helps to send out a link, especially if the name (comparator vs 
collation) is wrong ;-)

BTW, it was pointed out to us that the original email shouldn't have 
been sent to "Network Working Group", even though that is the name at 
the top of 
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt

Arnt Gulbrandsen wrote:
>
> As far as I know, this addresses, ignores or adds open issues for all 
> requests. If something is ignored, that's because other people wanted 
> the opposite, or because I overlooked it when I went over all the mail 
(Continue reading)

Arnt Gulbrandsen | 10 May 00:47 2006
Picon

Re: draft-newman-i18n-collation-09.txt just posted


John Cowan writes:
> Arnt Gulbrandsen scripsit:
>>  As far as I know, this addresses, ignores or adds open issues for 
>>  all requests. If something is ignored, that's because other people 
>>  wanted the opposite, or because I overlooked it when I went over 
>>  all the mail this week. I'm sorry about it in either case.
>>
>>  Review, please.
>
> Posted where? Neither rfc-editor.org nor ietf.org seems to have it.

http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt 
has it. Sorry. I posted that only an hour or two after the i-d editor 
told me it was posted (at that URL), which must have been too quickly 
for most mirrors.

Arnt

Arnt Gulbrandsen | 10 May 15:08 2006
Picon

Re: draft-newman-i18n-collation-09.txt just posted


Mark Davis writes:
> The release of this is timely (we didn't get notified of a 07 or 08 
> draft), since the Unicode Technical Committee is meeting next week, 
> and can discuss it.
>
> Could you indicate which of the items raised in the email of 
> 2006-02-21 from the Unicode Technical Committee have been addressed 
> in this release (and if not accepted then why)? That would help 
> greatly with the review. (I couldn't find any archive for discussion 
> of draft-newman-i18n-comparator where that email could be publicly 
> linked from, so I am appending it at the end of this message.) At a 
> quick glance, it appears that a number of comments have been 
> incorporated.

Lots. Some not. See below.

It is possible that some of my changes don't satisfy you. I had 
conflicting requests for many things. Feel free to repeat, rephrase or 
add arguments.

> Mark
>
> BTW, despite the subject of the message, the document is at 
> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt. 
> It helps to send out a link, especially if the name (comparator vs 
> collation) is wrong ;-)

Mea culpa. My apologies.

(Continue reading)

John Cowan | 11 May 15:38 2006

Re: draft-newman-i18n-collation-09.txt just posted


I propose that the procedure specified in draft-newman-i18n-collation-09
for getting new collations approved should be changed to the procedure
used for new language tags.  Instead of the requestor sending the
request to IANA, who sends it to the Collation Reviewer for discussion
on the list, and then the Collation Reviewer sends it back to IANA for
registration (or doesn't), remove the first pass through IANA.

Have people post directly to the list and work out the details.  When the
requestor thinks it's ready, the Collation Reviewer wakes up and then
either sends the latest draft of the request to IANA or else sends a
rejection (with reasons) to the list.  This lowers the load on IANA.

This scheme has worked very well for ietf-languages <at> iana.org for the
past 11 years.

--

-- 
John Cowan  cowan <at> ccil.org   http://ccil.org/~cowan
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."

Arnt Gulbrandsen | 16 May 18:21 2006
Picon

Re: draft-newman-i18n-collation-09.txt just posted


John Cowan writes:
> Instead of the requestor sending the request to IANA, who sends it to 
> the Collation Reviewer for discussion on the list, and then the 
> Collation Reviewer sends it back to IANA for registration (or 
> doesn't), remove the first pass through IANA.

Fine. Done.

Arnt

Arnt Gulbrandsen | 16 May 20:25 2006
Picon

Re: draft-newman-i18n-collation-09.txt just posted


Arnt Gulbrandsen writes:
> Mark Davis writes:
>> ...
>> At a quick glance, it appears that a number of comments have been 
>> incorporated.
>
> It is possible that some of my changes don't satisfy you. I had 
> conflicting requests for many things. Feel free to repeat, rephrase 
> or add arguments.

In -10 (which I'll send off once I finish work this evening) I've made 
another few changes.

>>>       > 2.4 Sort Keys
>>>
>>> The use of the term "collation canonicalization" to refer to sort 
>>> keys is very misleading. ...
>
> Changed; the text now speaks of sort keys. I'm afraid there still are 
> instances of the old term around, I found one today.

In -10, all should be dead.

>>> The term 'error' is also problematic, since what is really at issue 
>>> is a question of domain. For all those strings in the domain, 
>>> either 'equal' or 'not_equal' should be returned from the equality 
>>> function. For any string not in the domain, 'undefined' should be 
>>> returned.
>
(Continue reading)


Gmane