[Top] [All Lists]

Re: AD review of draft-ietf-sieve-3028bis-12

2007-03-29 23:28:22

On Fri, 30 Mar 2007, Chris Newman wrote:
Alexey Melnikov wrote on 3/29/07 18:15 +0100:
The text is trying to prevent people to do partial script execution. Any
suggestions how to improve the text?

Implementations MUST NOT execute any Sieve script test or command
subsequent to "require" if one of the required extensions is unavailable.

I like that.

Section 5.1 ***

There's some tricky interaction with IDN and EAI here.  It could be
clarified with text like: A Sieve implementation for use with Internet
email MUST support the use of IDN-encoded domain names [IDN] in the

Isn't this implied? I mean any ACE-encoded IDN domain name is a valid ASCII
domain name.

This is implied only as long as the SMTP infrastructure is 7-bit. But the present Sieve spec is written in such a way that it could be applied to an 8-bit infrastructure (such as XMPP or future UTF8SMTP which EAI will produce). So the question is do we want the ability to move a Sieve script from a 7-bit infrastructure to a UTF-8 infrastructure and have it continue to function in the same way?

Ah, I had read your original message as implying the opposite direction (UTF-8 domain arguments as matching IDN-encoded header/envelope), which would be a new requirement. Simply saying "MUST support use of IDN-encoded..." is insufficient, IMHO, as "use" does not clearly imply matching between encodings.

The direction you're suggesting makes sense to me...but I suspect we're going to need a "sieve in an EAI world" RFC anyway to cover everything that comes up from the EAI work. E.g., should 'envelope "from"' match against both the UTF8SMTP address and an ALTADDRESS, if any? How do you 'redirect' to an address w/ALTADDRESS (just loosen the syntax in

Note that some of those may be in new extensions, but some may simply be new requirements on implementations. 3028/3028bis describe the requirements on sieve implementations that operate on top of 2821/2822. Implementations that operate in other environments have other requirements, described in other docs, such as already seen in draft-ietf-lemonade-imap-sieve. An implementation in a UTF8SMTP/EAI environment can have additional requirements placed on it by a separate RFC. Of course, those requirements should be designed to ease script portability, as your suggestion does.

My technical preference is that user Sieve scripts should keep working when the infrastructure is upgraded as I don't like disrupting users.

Agreed, I'm just not sure we have enough knowledge right now to guarantee that.

Philip Guenther