Alexey,
Sorry, but I have to agree with Sam.
On Thu Oct 27 18:11:40 2005, Alexey Melnikov wrote:
From: Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
To: iesg(_at_)ietf(_dot_)org
CC: alexey(_dot_)melnikov(_at_)isode(_dot_)com
The :lower and :upper and other case-folding modifiers to the set
action do not seem to have a well defined case mapping for
internationalization. It is true that the ACAP i;ascii-casemap does
define a case folding table for part of Unicode. However I don't
understand how that's generally true or how consulting a comparator
will tell me which locale to use.
Please provide information on how the four ACAP comparator
operations
can be consulted to determine how to map case. Alternatively,
provide
another solution or extend the definition of ACAP comparator
sufficiently to meet your needs.
I count five, but I agree with the point - comparators act as a black
box, and the mere fact that one of the pre-existing comparators
happens to act *as if* it alters octets in the source octet strings
in a manner which coincidentally looks a bit like case folding
certainly doesn't mean that all comparators define some case folding
semantic.
Sieve breaks the model defined in ACAP in (at least) two places:
1) In the :matches match type, which defines an operation on
comparators which does not appear in ACAP; moreover, it defines it so
loosely, that it's impossible to detirmine what the behaviour should
be.
2) In the :lower, :upper, etc modifiers, which require access to the
transformed result of the comparator. Ned Freed and others have
argued that the result of :matches, which is in variables, should be
those parts matched by the comparator, which also breaks this model.
For what it's worth, I apologise for not having reviewed this
document earlier.
I think a good rule of thumb is that you need to extend comparators
themselves if the operation makes no sense with "i;ascii-numeric",
whose internal transformation format isn't even a string, and yet is
not defined to fail. PREFIX and SUBSTRING operations (which are
coalesced mistakenly into a single operation in the comparator draft)
are defined to fail with this, so logically Sieve's new operations
probably do as well, but this needs definitions.
Using "i;ascii-numeric" to translate a string using :upper makes no
sense - even if there were a defined mechanism for accessing the
internals of a comparator, the result wouldn't be a string - unless
you then define a mechanism for coercing the result back into a
string.
Using "i;ascii-numeric" as a comparator with :matches makes no sense,
therefore matching is inherently broken.
I really don't mind if people want to define a "Transform" or
"Normalize" operation on comparators, that's fine with me. Matches
would be fine too, although I'd prefer the use of special matching
comparators, in order to gain benefit without additional protocol
work in other places. The trouble is that nobody has.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw