Hi Philip,
--On March 29, 2007 11:19:34 PM -0700 Philip Guenther
<guenther+mtafilters(_at_)sendmail(_dot_)com> wrote:
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.
Yes - I always assumed that there would be a SIEVE for EAI extension to
allow SIEVE to work in an EAI environment. Shouldn't that be part of the
EAI WG since it is looking at SMTP/IMAP/POP etc in an EAI environment? I
would be somewhat reluctant to undertake that work here, but it seems to me
it should be done in parallel with the SMTP/IMAP/POP work so it can be
deployed and used alongside those when they get upgraded.
--
Cyrus Daboo