Subject: Updated Sieve environment draft posted

From: Ned Freed <[email-masked]>
Date: Mon, 10 Mar 2008 16:29:21 -0700 (PDT)

I just posted an update to the environment draft; it should be in the
repository soon. In addition to adding a note about using "name."
prefixes to group related standard items, I also rearranged the text
about IANA registrations a bit to make the group (hopefully) a little more
logical.

Please review and if this seems OK, it's time for last call.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Mar 2008 23:12:33 +0000

In my capacity of a technical contributor:

> about IANA registrations a bit to make the group (hopefully) a little 

I've reviewed the recent changes (and I've reviewed earlier versions of 
the document) and I believe the document is ready for publication.

In particular, I think the current list of attributes specified in the 
document is sufficient and is reasonably described.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 13 Mar 2008 12:59:07 -0400

On Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
> repository soon.

Seems short and sweet.

> In addition to adding a note about using "name."
> prefixes to group related standard items,

That note is actually the only thing that gave me pause.  When I read:

   > Extensions designed for interoperable use SHOULD be defined in
   > standards track or experimental RFCs.  Groups of standardized items
   > MAY choose to use a common name prefix of the form "name.".

it took me a few passes to realize that this was not recommending the
literal prefix string "name." (perhaps relating to the "name"
environment item) but recommending grouping related items by some prefix
"xxx." where "xxx" is replaced by some mnemonic for the category by
which they are related.  I dunno if that's even worth mentioning, but
there it is, mentioned.

A couple of other musings, again perhaps not worth mentioning, but
while I'm here:

There is a "host" item listed, which is the FQDN of the local host.
It seems to me that one might want to know the host-only part of that
string.  One could obtain it in a round-about way by using the "domain"
environment item and the "host" item; but is it worth adding "host-only" ?

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.

That's all..

mm

---

From: Ned Freed <[email-masked]>
Date: Thu, 13 Mar 2008 16:30:09 -0700 (PDT)

> which they are related.  I dunno if that's even worth mentioning, but

Fair enough. When the document is next updated I will add ", where "name" is a
string that identifies the group of related items." to the end of the last
sentence.

> environment item and the "host" item; but is it worth adding "host-only" ?

Frankly, I think the use of shortform names is a bad thing that should be
discouraged whenever possible. (IT uses them extensively here at Sun and they
cause no end of problems.) I'm therefore very reluctant to add such an item.

> 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.

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.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 13 Mar 2008 20:47:01 -0400

> 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.

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.  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.

> values from environment tests, but I eventually decided it wasn't worth it.

Different perspectives, I guess.  I like having the "environment" 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.

Yours,
mm

---

From: Philip Guenther <[email-masked]>
Date: Thu, 13 Mar 2008 22:18:43 -0400

On Thu, 13 Mar 2008, Ned Freed wrote:
...
>> There is a "host" item listed, which is the FQDN of the local host. It 
>> seems to me that one might want to know the host-only part of that 
> Frankly, I think the use of shortform names is a bad thing that should 
> be discouraged whenever possible. (IT uses them extensively here at Sun 
> and they cause no end of problems.) I'm therefore very reluctant to add 
> such an item.

I agree.  Unqualified hostnames should never appear in protocols and, 
IMHO, are only useful in space-constrained interactive environments, where 
the user can obtain the full form if they have any doubt.

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

There's a pattern missing there.  Regardless, the empty substring test is 
probably more efficient:
 	if environment :contains "item" "" { ... }

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Thu, 13 Mar 2008 21:03:37 -0700 (PDT)

> to have it at all, or than having it done separately with yet another

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

> about a possible "variables" namespace, not the "environment" verb.

Right.

>  In
    
Yes, that's an issue with the namespace approach.

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

I think you mean test, not verb.

> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 14 Mar 2008 11:15:58 +0100

Ned Freed writes:
>> 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.

Yes. I like the simplicity and brevity of the document, and I like that 
it doesn't depend on variables.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Fri, 14 Mar 2008 06:34:46 -0700 (PDT)

> There's a pattern missing there.

Right, sorry about that.

> Regardless, the empty substring test is
> probably more efficient:

This almost always works, but not in the case where the environment
item has the null string as a possible return value. Of course in every
case I can think of a null value is going to signify "information not
available", and I cannot think of a use-case where a script would want
to act differently given "item not supported' versus "information not 
available".

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Mar 2008 21:37:12 +0000

>use-case for environment is as a test.
Agreed.
I am planning to implement both environment and variables at some point. 
But environment as written is just a couple of hours of work, while 
variables is more like a couple of weeks of work. So I would rather not 
tie environment to variables.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 15 Mar 2008 14:16:30 -0400

> tie environment to variables.

Except that I made no suggestion that they be tied, and I even said that
I liked the fact that the test(*) doesn't depend on variables.  What I
opined was that the draft could state what the behavior would be in the
presence of the variables extension -- analogous to how it already
states what the behavior is in the presence of the relational extension.
Not that it require variables.

I hadn't intended to follow up again, not having anything new to add,
but since two people commented on a perceived requirement to implement
variables according to my remarks, I figured I would.  To me, specifying
a variables namespace here adds utility and symmetry, which appeals to
me (although that's not always a complete justification for anything, I
fall on that side here), and won't require any later extension to do it,
which also appeals to me.  At any rate it's not a huge deal.

mm

(*)tho I did say "verb" - it's a bad habit of mine, like nailbiting.

---

From: Philip Guenther <[email-masked]>
Date: Sat, 15 Mar 2008 17:36:00 -0400

On Sat, 15 Mar 2008, Mark E. Mallett wrote:
> presence of the variables extension

One barrier to implementing sieve extensions is exactly that the 
intersection of two extensions may require special handling.  While this 
is true by necessity for match-types and comparators, we should fight the 
tendency to add special cases for other combinations that aren't 
completely necessary.

> -- analogous to how it already

This particular special case seems unnecessary to me.  It appears to have 
been inherited or based on the similar exception for the 'envelope' test. 
IMHO, that behavior should not be propagated to 'environment'.  If you 
want to test whether an environment item returns the empty string, then 
just do exactly that!
 	if environment :is "foo" ""

My opinion is that the correct model for relational's :count is that it 
tests against "the number of distinct entities that would otherwise be 
matched against".  I.e., it's the number of different strings that could 
have been matched by <<:matches "*">>.  The count will be zero iff there 
were no entities to match against.

For environment, that would mean that the count will be zero if the item 
does not exist.  The current draft's exceptional handling of empty strings 
is a wart that does not increase the expressiveness of the test and should 
be removed.

(Stepping further up the abstraction ladder: a test command defines how to 
generate a set of zero or more strings.  The comparator and match-type 
arguments then define how that set of strings is matched against the keys. 
The :count match-type says "take the decimal representation of the 
cardinality of the set of match strings, collate (order) that against each 
key using the indicated comparator and return true if they collate in the 
direction indicated by the relational-match argument."  When we define new 
test commands, we should *ONLY* be specifying how it generates a set of 
strings to match against.)

Philip Guenther

---

From: Philip Guenther <[email-masked]>
Date: Sat, 15 Mar 2008 17:42:30 -0400

On Fri, 14 Mar 2008, Ned Freed wrote:
...
> item has the null string as a possible return value.

Ummm, what?  Are you saying that there exists some case where
 	if environment :matches "item" "*" { ... }
and
 	if environment :contains "item" "" { ... }

would return different results?

If that's not what you meant, then I don't understand what you're saying.

I strongly believe that <<:matches "*">> and <<:contains "">> MUST have 
the same result with *any* combination of test and comparator.

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Sat, 15 Mar 2008 14:46:01 -0700 (PDT)

> would return different results?

Sorry, my mistake, I was thinking of :is.

> the same result with *any* combination of test and comparator.

Certainly should be true of all tests and any comparator we've defined so far,
not entirely sure it will extend to all future comparators.

				Ned