ietf-mta-filters
[Top] [All Lists]

Re: IESG review of draft-ietf-sieve-variables-07.txt

2005-10-27 13:01:27

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

<Prev in Thread] Current Thread [Next in Thread>