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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 27 Oct 2005 18:11:40 +0100

IESG has reviewed draft-ietf-sieve-variables-07.txt and had to DISCUSS 
raised against it.

Russ Housley:

  This document updates RFC 3028.  This needs to be indicated in the
  Abstract.

The discuss comment from Sam is shown below:

-------- Original Message --------
Subject: 	discuss: draft-ietf-sieve-variables
Date: 	Wed, 26 Oct 2005 14:41:34 -0400 (EDT)
From: 	Sam Hartman <[email-masked]>
To: 	[email-masked]
CC: 	[email-masked]

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.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 27 Oct 2005 21:17:27 +0200

> sufficiently to meet your needs.

this is indeed the weakest part of the variables spec, I admit the use
of a comparator with SET is little more than handwaving to appease the
i18n concious :-).  the text is even careful to avoid implying that the
comparator _has_ such a mechanism:

        The comparator specified SHOULD be consulted to establish which
        locale to use.

"consulted" isn't very normative.  it was a trick, and Sam caught me.  I
had hoped this would slide, and later we could fix up comparators
"properly" by adding two new operations (upper case and lower case).
however, such operations can hardly be called comparisons, and they're
unary, not binary, so it's probably not such a hot idea.

another option is to leave out the whole comparator thing, and just say
(as it does already) that US-ASCII MUST be supported.  after all, all
strings in Sieve are UTF-8 encoded characters from the ISO 10646
repertoire anyway, so by not saying anything about it, we make it a
quality of implementation issue.  which it would be, _anyway_.

(at the same time, we could get rid of the Unicode reference.)

thoughts?
-- 
Kjetil T.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 27 Oct 2005 20:43:24 +0100

Alexey,

Sorry, but I have to agree with Sam.

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Oct 2005 10:54:14 +0100

>unary, not binary, so it's probably not such a hot idea.
Indeed. Let's not call it "comparator".

>quality of implementation issue.  which it would be, _anyway_.
I think it is the quickest way to address the issue. Besides, one can 
document/implement something like ":upper_cyrillic" modifier.