Sieve Email Filtering: Variables Extension
draft-ietf-sieve-variables-08

[Ballot discuss]
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.

IANA Comments:
Upon approval of this document the IANA will register a new Sieve extension for variables.  This registration will go in the following registry:
http://www.iana.org/assignments/sieve-extensions

AD evaluation comments:

The Abstract should be more clear about the focus of the document.  It describes "This extension", but it doesn't explain what's being extended.

RFC 2234 has been obsoleted.  Can the reference to 2234 be updated to refer to 2234bis instead?

Shepherd write-up:

1). Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG for
publication?

Yes and yes.

2). Has the document had adequate review from both key WG members and
key non-WG members?

Yes and Yes.

Do you have any concerns about the depth or breadth of the reviews
that have been performed?

No.

3). Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No (has been already reviewed by several people from Security Area)

4). Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or whether there
really is a need for it, etc., but at the same time these issues have
been discussed in the WG and the WG has indicated it wishes to advance
the document anyway.

No concerns, see the write-up below for more details on some postponed
issues.

5). How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

The document has strong support from the WG members.

6). Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7). Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes

8). Does the document a) split references into normative/informative,

Yes

    and b) are there normative references to IDs, where the IDs are not
also ready for advancement
    or are otherwise in an unclear state? (Note: the RFC editor will
not publish an RFC with normative
    references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

There are two normative and one informative reference to an I-D. One
normative reference is to the updated SIEVE base spec document which has
recently completed working group last call and which we anticipate being
submitted to IESG soon. So any hold up of this document should be short.

The second normative reference is to the Sieve relational tests
extension (draft-ietf-sieve-3431bis-01.txt) which is ready for the WGLC.
The difference between draft-ietf-sieve-3431bis-01.txt and RFC 3431 is
so minor, that reference to either document would be good.