ietf-mta-filters
[Top] [All Lists]

Re: Updated Sieve environment draft posted

2008-03-13 21:34:59

On Thu, Mar 13, 2008 at 04:30:09PM -0700, Ned Freed wrote:

I also think that the draft could benefit by providing for some behavior
in the presence of the "variables" extension, e.g. by defining a
namespace such as "env." and stating what value is returned if the item
is undefined in the implementation.  I realize that one could obtain the
values by using :matches, wildcarding, and variable assignments;
having namespace support would be more straightforward.

First of all, the specification says that any test against an unknown
item must fail unconditionally. This provides a simple way to check and
see if a given item is available:

   if environment :matches "item" {...}

This test only succeeds if "item" is defined. Since this doesn't appear
to be obvious I think I'll add a note about it to the text.

Actually I think it is pretty obvious, I don't think that needs to be
clarified.  What I was saying is that while you can indeed use
":matches" to get the value into a variable:

    if environment :matches "domain" "*" { set "domain" "${0}"; }

using a variable namespace would be more straightforward, and much more
efficient.  e.g.:

    set "domain" "${env.domain}";

and that basically it would be good to have that specified here than not
to have it at all, or than having it done separately with yet another
capability.

It's a bit more elegant but I'm just not convinced it is worth it.

I may be missing the point of your reply.  It occurs to me that you are
replying to my phrase "stating what value is returned if the item is
undefined in the implementation" -- but that is in a sentence that is
about a possible "variables" namespace, not the "environment" verb.

Right.

 In
evaluating a variables namespace reference to a non-existent or
unsupported item, say "${env.remote-host}" when remote-host isn't
meaningful, or "${env.foobar}" when foobar isn't a real item, the
hypothetical text that addresses the variables namespace would have to
describe what value is returned in those situations.  As you say, the
behavior of the "environment" action is pretty clear already.
    
Yes, that's an issue with the namespace approach.

I did consider using namespaces as a means of returning multiple/structured
values from environment tests, but I eventually decided it wasn't worth it.

Different perspectives, I guess.  I like having the "environment" verb,

I think you mean test, not verb.

as it doesn't require variables, but also having the information
available via a variable namespace seems clean to me too since it builds
on language elements and concepts already out there.  But I can see some
of the drawbacks too: one being that it would make implementation of
this extension slightly harder/slower/less likely for any product that
also implements "variables" if this extension mandated adding a
variables namespace.  But only slightly.

That's my main concern here - I want to keep this simple. I think the main
use-case for environment is as a test.

                                Ned