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?
Perhaps:
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
key-list.
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
2.4.2.3?)?
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