Subject: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Nov 2006 21:16:08 +0000

Ned has published the environment extension (Thanks Ned!). I would like 
to solicit some reviews.

Subject: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt
From: [email-masked]
To: [email-masked]
Date: Wed, 15 Nov 2006 15:50:01 -0500
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Sieve Email Filtering:  Environment and Ihave Extensions
	Author(s)	: N. Freed
	Filename	: draft-freed-sieve-environment-ihave-00.txt
	Pages		: 11
	Date		: 2006-11-15
	
   This document describes the "environment" and "ihave" extensions to
   the Sieve email filtering language.  The "environment" extension
   gives Sieve access to information about the environment where the
   Sieve interpreter is running.  The "ihave" extension provides a means
   to write scripts that can take advantage of optional Sieve features
   but can still run when those optional features are not available.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-environment-ihave-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-freed-sieve-environment-ihave-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-freed-sieve-environment-ihave-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Ned Freed <[email-masked]>
Date: Wed, 15 Nov 2006 13:39:43 -0800 (PST)

> Ned has published the environment extension (Thanks Ned!). I would like

Yes please. I'm especially interesting in comments on the initial list of
environment items, how the IANA registory is arranged (I'm toying with the idea
of telling IANA to build a table with specific colums and giving them the
initial contents of that table instead of a bunch of separate registration
forms), the semantics of ihave, and whether or not the lack of options in
these tests is a good idea.

One thing I noticed while writing up ihave is that we currently place
no syntax requirements on capability strings. I think that at a minimum
we should prohibit ";" in capability names - this way no capability name
will ever conflict with a comparator name. Of course this is a base
specification issue.

				Ned

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Nov 2006 07:41:15 -0800

Should there be some guidance for the 'host' value when a SIEVE  
script is running on the localhost?

In the long run, should "ihave" replace "requires" since it subsumes  
that functionality?

thx,
Lisa

---

From: Aaron Stone <[email-masked]>
Date: Thu, 16 Nov 2006 08:38:33 -0800

> In the long run, should "ihave" replace "requires" since it subsumes  

Let's say we dropped Ned's suggested requirement that actions must be
used inside of ihave blocks testing for them. Then we could prepend
scripts with test blocks that check for ihaves and say something else
otherwise:

    require ["notify", "ihave"];

    if not (ihave "vacation") {
        notify :method "mailto:myself@myserver"
            :message "Sieve error: vacation is not available.";
        stop;
    }

    vacation "I'm out of the office till later! Ciao!";

This basically just moves the "vacation not available" message from
script upload time to script run time. 

Aaron

---

From: Ken Murchison <[email-masked]>
Date: Thu, 16 Nov 2006 12:34:27 -0500

> In the long run, should "ihave" replace "requires" since it subsumes 

I think "requires" still has use during upload.  If a script is written 
so that all extensions that are being used outside of "ihave" are listed 
in "requires", then the implementation can simply check this list 
against the optional functionality it supports and refuse to accept the 
script at upload time (or provide a warning) if it doesn't support one 
or more of the "requires".  If we eliminate "requires" then an 
implementation that wants to perform this refusal/warning has to parse 
the entire script to look for "ihave"-unprotected optional features.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 16 Nov 2006 18:51:08 +0100

Ken Murchison writes:
> I think "requires" still has use during upload.

AOL.

> If a script is written so that all extensions that are being used 
> outside of "ihave" are listed in "requires", then the implementation 
> can simply check this list against the optional functionality it 
> supports and refuse to accept the script at upload time (or provide a 
> warning) if it doesn't support one or more of the "requires".  If we 
> eliminate "requires" then an implementation that wants to perform 
> this refusal/warning has to parse the entire script to look for 
> "ihave"-unprotected optional features.

Or optional features within the wrong ihave.

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 16 Nov 2006 12:41:38 -0500

Ned Freed wrote:
> environment items,

I think the "place" item seems a bit awkward.  Possible alternatives 
might be "type" (as in product type), "execution-env", 
"evaluation-time", "processed-by", or some other permutation of the above.

> will ever conflict with a comparator name. Of course this is a base

Agreed.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 12:15:18 +0000

Ned Freed wrote:

>forms),
Yes, this seems like a simpler solution for everyone.

> the semantics of ihave
This might be difficult to implement for me, but so far I can't think of 
anything wrong with the way it is described.

>, and whether or not the lack of options in these tests is a good idea.
>
Lack of a match type or a comparator in ihave seems reasonable.

>will ever conflict with a comparator name. Of course this is a base
I agree that this needs to be fixed in 3028bis.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 12:02:42 +0000

Ned Freed wrote:

>Yes please.
Some comments after a quick scan through the document:

In section 4.1:

>     "place"   => Sieve processing is normally performing around or after
>                  the time of final delivery. This item provides
>                  additional information about the relationship to final
>                  delivery. Possible return values are "MTA", meaning the
>                  Sieve is being evaluated before final delivery, "MDA",
>                  meaning evaluation is occurring during final delivery",
>                  and "UA", meaning evaluation is occurring after final

Why not "MUA" for consistency?

>                  delivery.

I would also like to add an environment item for protocol invoking the 
Sieve engine. The item value can be one of "SMTP", "LMTP" and "IMAP". 
(Or can just reuse the WITH field registry for the Received header field).
Also an item that can convey that there is a single SMTP recipient would 
be nice as well.
Both can be used with the reject action.

Also the [expired] draft-ietf-lemonade-imap-sieve-00.txt draft defines 
the following environment items (as IMAPSieve.<var> variables):
 cause
 mailbox
 changed.flags
 changed.annotations.

But I guess their registration can be done in the IMAP Sieve draft itself.

The IANA registration section should use the updated Sieve extension 
registration template from 3028bis.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 12:11:15 +0000

One more comment:

 >5.  Ihave Test
 [...]
 >   Unlike most Sieve tests, ihave accepts no match or comparator
 >   arguments.  The type of match for ihave is always ":is" and the
 >   comparator is always "i;ascii-casemap".

3028bis, section 6 says:
 Capability string are case-sensitive

So, the default comparator must be "i;octet".

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Nov 2006 07:29:48 -0800 (PST)

> So, the default comparator must be "i;octet".

Yes. I'll change it.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Nov 2006 07:33:56 -0800 (PST)

> Why not "MUA" for consistency?

Sure, why not?

> (Or can just reuse the WITH field registry for the Received header field).

It's not clear to me that that this provide sufficiently different
information than the place value does.

I also don't believe IMAP is a legal value for with, plus there are a whole
bunch of registered values for WITH that may or may not make sense here.

> Also an item that can convey that there is a single SMTP recipient would

IMO this isn't an environment test, but rather an envelope extension. And there
are a bunch of other things we need to add to envelope besides this - NOTARY
information being the most obvious. I considered defining an envelope extension
in this document, but decided it was too much to start with. If people feel it
wouldn't be too much bloat I can go ahead and put it in as a separate
extension.

> But I guess their registration can be done in the IMAP Sieve draft itself.

I don't feel strongly about it either way. If people think it woul be best
to have these here I can copy the definitions over.

> registration template from 3028bis.

Yes. I'll update them here and in the data/index document. I note that vacation
is in the RFC Editor queue (waiting for the base spec and variables) and
needs a similar update - I guess I'll do that during AUTH48.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 16:09:11 +0000

>> Why not "MUA" for consistency?

I was just wondering if you had other "UA"s in mind.

> information than the place value does.

Well, one can run Sieve engine MDA using SMTP or LMTP.

> I also don't believe IMAP is a legal value for with,

I know. This was just a suggestion if you don't want to define a new 
registry.

> plus there are a whole bunch of registered values for WITH that may or 
> may not make sense here.

I have no problems with things like SMTPS.

> IMO this isn't an environment test, but rather an envelope extension.

Ok.

> And there are a bunch of other things we need to add to envelope 
> besides this - NOTARY

In a separate document, please. You've also promised to do envelope 
"auth" test ;-).

> to have these here I can copy the definitions over.

Barry should comment on this.

> needs a similar update - I guess I'll do that during AUTH48.

Yes.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 16:43:07 +0000

Cyrus Daboo wrote:

> Hi Ned,
>
> --On November 17, 2006 7:33:56 AM -0800 Ned Freed 
> <[email-masked]> wrote:
>
> Yes please. We need to make sure we do that for the other documents in 
> the queue as well. I can't remember - do chairs get notified of AUTH48?

Yes.

> If so, we can prod authors to do that update when the time comes. We 
> will also need to inform IANA that actions they have already taken on 
> those documents may need to be re-done to match the new template.

Philip has suggested to do this in one go by talking directly to IANA.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 17 Nov 2006 11:40:05 -0500

Hi Ned,

> needs a similar update - I guess I'll do that during AUTH48.

Yes please. We need to make sure we do that for the other documents in the 
queue as well. I can't remember - do chairs get notified of AUTH48? If so, 
we can prod authors to do that update when the time comes. We will also 
need to inform IANA that actions they have already taken on those documents 
may need to be re-done to match the new template.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Nov 2006 09:20:32 -0800 (PST)

> queue as well.

If my notes are correct, the only two specs we have in the RFC Editor
queue are base and variables.

> I can't remember - do chairs get notified of AUTH48?

Yes they do, but only for WG docs. Date-index and environment-ihave are
individual submissions, but when the time comes I'll try and cc the chairs
on editing discussions.

> If so,

Well, I guess the sort-of good news is that we don't have that many documents
so far along that we can't fix them now.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2006 17:31:21 +0000

> queue are base and variables.

"http://tools.ietf.org/wg/sieve/" says we have 6.

> so far along that we can't fix them now.

Right.

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Nov 2006 15:09:54 -0800 (PST)

> "evaluation-time", "processed-by", or some other permutation of the above.

I agree that place isn't great. Of these, I prefer evaluation-time. I'll
change the draft accordingly.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 19 Nov 2006 12:42:05 -0800 (PST)

> script is running on the localhost?

I'm not sure what you're getting at. You're running on the "local" host pretty
much by definition, I'd say.

Are you asking about what to do when the name of the host you're running on
isn't known or has been given some silly default name like "localhost"? In such
cases I think it would be best to regard "host" as unsupported.

> In the long run, should "ihave" replace "requires" since it subsumes

Well, it can't replace it completely since you have to require ihave...

I don't really know what the end game will be here. My plan is to move forward
with this as an experimental specification, not standards track. I'm reluctant
to push for standards-track status because past experience with mechanisms like
this has not been great - too many devils in the details.

I'm hoping that given knowledge of, say, how PostScript's use of conditionals
in comments didn't really pan out (implying that the mechanism needs to be well
integrated into the language), we can get the details right this time. But only
time will te, as ihave has beenll. And even if we get the details right,
there's no guarantee of uptake. The require approach is simpler, and maybe
nobody will care enough about the ability to use the same script in dissimilar
environments to want to deal with the added complexity.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Nov 2006 15:37:58 +0000

Ned Freed wrote:

> with this as an experimental specification, not standards track.

I tend to agree. Even though I like "ihave" I will have hard time 
implementing it due to how lex/yacc is being used by Sieve parser. 
Skipping unrecognized actions/tests would be tricky.

I would also like the environment extension to be published on Standard 
Track, which suggests splitting up the document.

> I'm reluctant

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 27 Nov 2006 16:53:54 -0500

On Thu, Nov 16, 2006 at 08:38:33AM -0800, Aaron Stone wrote:
> used inside of ihave blocks testing for them.

That would be my quibble with 'ihave' as well.  While it might be
interesting to have a capability enabled for a block scope, I don't
think that doing this via a side-effect of a test inside of 'if' would
be the way to go about it.  It creates too much of a magical connection
between the evaluation of the test inside of the 'if' and the code block
that follows the 'if', and I think that would cause confusion to script
writers and Sieve language implementers, both.  It also asks for too
much context to be known inside the 'if' expression evaluator, e.g.:

   if not ihave "vacation" { ... }
   elsif something-else { ... # is vacation enabled here? }
   else { ... # how about here? }

the "ihave" has to know a lot about what's around it, like if there's a
'not' out there that, at least in my implementation, would actually be
applied after the 'ihave' test was already disposed of.  That's only a
very simple perversion, I can imagine others more complex :)  While I
could implement it, I wouldn't like to...

If one wants block scope of capabilities, I would think there are other
ways to accomplish it.  One way would be to have a new control command
with an attached block that could be else'd, e.g.:

    enable "vacation" {	... }
    else { ... }

Or simply separate the test and the enable, e.g.:

    if ihave ["vacation", "notify" ] {
        enable ["vacation", "notify"];
	   ...
    }

If desired, this could be defined so that the effect of the enable went
away when its containing block ended.  I dunno if I would want that, I
guess I'd have to think about it; I tend to prefer more explicit
twiddling (e.g. by also having a complementary "unenable").  Then again,
I don't really see why one would want the capability to go away once
enabled.

Also I wonder about this bit:

   > Ihave is designed to be used with extensions that add tests, actions,
   > or comparators.  It MUST NOT be used with extensions that change how
   > the content of Sieve scripts are interpreted such as the variables
   > extension [I-D.ietf-sieve-variables]

Why?

mm