Subject: [sieve] WG status

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Sep 2010 11:15:45 -0400

Hi folks,
Here is the current status for the WG with some actions items for authors 
and chairs:

Documents:

draft-ietf-sieve-include-06 - authors to do update based on comments from 
last meeting and reviews. Once done, and the shepherd (Barry) is happy, it 
can probably go to the IESG or Barry may decide another WG last call is 
needed.

draft-ietf-sieve-notify-sip-message-02 - no comments from WG last call. We 
did have a detailed SIP expert review done, and the authors need to respond 
to that.

draft-ietf-sieve-notify-presence-00,
draft-ietf-sieve-vacation-seconds-00,
draft-ietf-sieve-autoreply-00 - as agreed at the last meeting these are 
ready for last call. Therefore I intend to issue last calls on all three of 
these later today.

draft-ietf-sieve-external-lists-02 - as agreed at the last meeting this is 
ready for last call. That will be issued later today.

draft-ietf-sieve-regex-01 - expired. Authors please update and provide 
status on where you think this draft is. What issues need to be discussed 
by the working group?

draft-ietf-sieve-imap-sieve-00 - expired. Authors please report. My intent 
is to issue a last call on this once we have completed the other last calls 
mentioned above.

draft-ietf-sieve-convert-00 - authors to update based on comments from the 
last meeting.

So, the plan is to inundate this working group with four last calls. Please 
find time to review these documents are provide any feedback (including a 
simple approval message if you read it and are happy with it as-is). I am 
sure the ADs can chip in and comment, but lack of feedback in working group 
last calls is a cause for concern and may hinder our ability to proceed 
with IESG processing of these documents.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 27 Sep 2010 12:17:57 -0400

> can probably go to the IESG or Barry may decide another WG last call is

There's an open question of what, if anything, needs to be said about
the interaction between -include and managesieve.

>From my IETF 78 notes:
    * Needs reviews, especially from Ned, also from others.
    * I will revise the draft to keep it from expiring, chairs will
ask Ned again for review.

I thought I had already posted a rev of it for that purpose, but I see
that I didn't.  I will now.  I'd rather have Ned's review before WGLC,
but during is fine as well.  I'm very reluctant to send this to the
IESG without reviews from Ned and at least two or three others who
have given it thorough thought.

Barry

---

From: [email-masked]
Date: Mon, 27 Sep 2010 20:32:10 -0700 (PDT)

> have given it thorough thought.

I just finished reviewing the latest version. The good news is almost all of
the semantic mismatch problems have been addressed, but there are still a lot
of other issues.

Section 1.1, second paragraph. The required support for Sieve environment
should be mentioned here.

> [[anchor2: Note about identity: We might want to use Sieve to impose
>   fine-grained access controls.  In final delivery, there's no identity
>   for the "filer".  Here, there is: the logged-in IMAP user.  How do we
>   get at that identity?]]

I don't see why this cannot be done with one or more environment items. As a
concrete proposal, I'd suggest having two: The user id and the primary email
address associated with the "filer". (These may be the same on some systems.)

Section 2: Thinking about it, "the IMAP IMAPSeive extension" sounds prety
swkward and redundant. Is there any reason not to simply call this the IMAP
SIEVE extension? (Or is it too late to change this?)

> [[anchor3: Sieve has no way to get the annotations, so is there
>    really value in being told about annotation changes here?  Maybe push
>    that into a sieve-annotations extension later.]]

Another problem is that IMAP ANNOTATE is currently experimental, which could
make getting this onto the standards track much harder. I think the handling of
annotations should be pushed off another specification.

> 2.3.1.  Changes to Metadata

Maybe I'm missing something, but I don't see any actual changes to the metadata
extension in this section. All it does is use metadata for a particular
purpose. How about changing this to "Use of Metadata"?

Section 2.3.1: Managesieve script names are implicitly qualified by the
authentication credentials used to access the server. Although RFC 5804 says
nothing about how "active" Sieves are associated with a mailbox, the obvious
approach is that the same credentials that identify you as the owner or a given
mailbox will, if used in ManageSieve, result in a SETACTIVE command associating
the named Sieve with delivery to that mailbox. (This probably should be stated
explicitly in a future revision of ManageSieve, because without knowing this
relationship holds it makes writing a useful client to manipulate Sieves nearly
impossible.) Also note that this in no way dictates how an implementation
actually performs this association. SETACTIVE could be implemented by pushing
the script from the ManageSieve server to the IMAP server, or by having the
IMAP server fetch the script from the ManageSieve server.

Anyway, the present draft carries this association much further, mapping an
entire collection of named scripts (presumably all associated with the same set
of authentication credentials to each mailbox, along with a bit of handwaving
about how there might be a distinguished collection that's associated with the
entire server. Of the immediate implications of this is it constrains the
implementation choices for hooking ManageSieve up to IMAP. Another is that
there's no way to share scripts by referencing one in a different collection.

The draft also seems to think that by not explicitly requiring ManageSieve, it
makes lots of other implementation approaches possible. But this isn't really
true. The draft is quite clear that what appears in value.shared under
"/IMAPSieve/Script" is, with the exception of the metadata: prefix, just a
name. There are any number of potential storage locations and methodologies
(LDAP with single entries for each user is the obvious one) where this doesn't
map very cleanly if at all.

But the real question is why should be limit ourselves this way? Why not make
the contents of "/IMAPSieve/Script" a URL? (The metadata: prefix can then be
defined as a URL.) If we want to reach into ManageSieve, use a sieve: URL. (I
do see a big problem with this currently - RFC 5804 appears to have badly
botched the specification of sieve: URLs - the authority field is mandatory
when it shouldn't be, and the owner field is encoded into the URL path when it
should have been extracted from the authority field if it is present. The way
it's done now, you cannot write sieve:///scriptname and have it mean what it
should mean: Select out of the mailbox owner's scripts.

Now, there is no doubt that allowing URLs creates additional concerns, mostly
security related. But we've dealt with this sort of thing before, e.g., in
BURL. All we have to say is that metadata:foo MUST be implemented and sieve:bar
(modulo some fixes to RFC 5804) SHOULD work if ManageSieve is available.

If this goes too far, then at a minimum I believe this section needs to be
more explicit about how, if ManageSieve is used, the mapping from script
collections in ManageSieve to a mbilbox works. 

> [[anchor4: Redirect assumes message can be submitted as is - not a
>    valid assumption in this context.  What do we do if the decision is
>    "redirect" and there's not enough information to do it?  Also, some
>    have been concerned about, say, a flag change that has the Sieve
>    effect of forwarding the message somewhere.  Perhaps we should just
>    forbid redirect.]]

I think the solution here is to explicitly say that redirect does a SUBMIT
operation with the redirect address as the RCPT TO. The MAIL FROM SHOULD
be set to the address of the mailbox owner. The text should note that SUBMIT
servers are allowed to do message fixup, but if the message is missing
any required header fields it MAY be rejected by the server.

Section 3.5 - Does requiring reject generate an error, or do you have to
actually try and use it? I would prefer for the text to state that requiring
reject MUST generate an error. The only downside I see is that this might
prevent you from using the same script in IMAP that you do for deliveries,
but since you cannot count on the require being allowed, I don't think that's
a big problem. (And note that you can always use ihave to work around
this issue.)

This section also needs to be updated to mention ereject as well as reject.
And I see no mention of the envelope or notary extensions in this document,
both of which need to be banned.

Better still, merge this section with 3.10 (vacation) and just have a list
of all the extensions known to be invalid in IMAPSieve.

> [[anchor5: Should editheader be allowed to change header fields that
>    aren't saved in place, such as for redirect or fileinto?  Editheader
>    would still have to be banned for "keep", but not otherwise.]]

I think this change would be a good idea.

> [[anchor6: Should this just require imap4flags?  Some implementors
>    have said they wouldn't bother with it without the ability to
>    manipulate flags.  And what values of flags does it see -- before or
>    after the change?  If it changes them, can it see the originals?  Can
>    it reset changes?]]

First, I think imap4flags should be required, just like environment is
required.

In hindsight, I guess we should have defined imap4flags with semantics similar
to editheader, with uses in other contexts always starting out with an empty
flag set. But's it's much too late to change this now.

The obvious thing to do here is to say that the internal flag state variable
starts out set to the flags the message was going to recieve. But this is
actually a little problematic, because AFAICT there's no way to copy the
setting of the internal variable to a real variable so you can manipulate it as
a string.

The altnerative is some sort of special variable, or maybe a currentflags
environment item. Absent use cases where the current flag list needs to be
examined as a string, I don't see sufficient cause to do this. (And keep in
mind that we have the changedflags environment item to tell us what flags
have changed.

This section also needs to discuss how use of :flags interacts with 
flags that are set by other means.

Section 3.10 - merge with 3.5, per above discussion.

> [Spamtest] [[anchor7: We need to say something about the spamtest/
>    virustest extension.  We need to be able to scan appended messages.
>    And we can't use headers to communicate spam status, because the
>   message is immutable.  What should we say here?]]

I disagree. There are lots of extensions that define tests on or derived from
message content: relational, variables, spamtest, virustest, body, date, index,
and subaddress. AFAICT the difference between delivery time and IMAP store
Sieve has no material effect on any of these. I think the right thing to do is
simply list all the ones that have been published that work here and say that
there's no problem using them.

As for the issue of status being communicatd via headers, this is precisely the
problem that spamtest/virustest solves: The information is kept out of band,
and in a universal format. To the extent there is a problem here, it is out of
scope for this draft: Some spam filters, notably ones that use milter, are
incapable of communicating via a mechanism like spamtest/virustest. If the
specific virtues of using spamtest/virustest needs to be spelled out, an
example would be a great way to do that.

There's one other extension that needs to be discussed, though - mime-loops.
The test part is fine, but the message modification parts, not so much.

Section 3.11:

   Implementations MAY invoke different Sieve scripts for the different
   conditions described in this document (append, copy, flag changes,
   annotation changes).  If the actions to be taken are common, and the
   implementation supports the [Include] extension, the common script
   code can be included as specified there.

Really? I don't see how the single Sieve script per mailbox model allows for
different scripts for different conditions.

Section 3.15: Defer to annotate extension draft.

Section 3.16: 

   This extension does not affect the operation of any tests or
   comparisons.

Well, it invalidate at least one test: envelope, and may alter the behavior
of hasflag on the internal variable. So this is incorrect. I suggest changing
this section to say that the behavior of tests in the Sieve base (header and
address) is unchanged. Other tests are by definition extensions.

Section 4, second example: The use of notify appears to be aligned with the old
notary draft, not the current specification.

Section 5: Loops can also be caused by redirect. Based on past experience with
IESG review, this needs to be discussed here.

Section 6.5: Defer to future annotations extension.

Section 7.1 - the reference:

   [Manage]   Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
              Managing Sieve Scripts", RFC editor queue, http://
              tools.ietf.org/html/draft-ietf-sieve-managesieve,
              January 2009.

needs to be updated to refer to RFC 5804.

That's it!

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Sep 2010 11:26:34 -0600

On 9/27/10 9:15 AM, Cyrus Daboo wrote:

> draft-ietf-sieve-external-lists-02 - as agreed at the last meeting this
> is ready for last call. That will be issued later today.

I've completed an "AD review" of that one (I'll be the sponsoring AD
because Alexey is one of the authors). Overall it looks good. Here are a
few comments...

Section 2.2 states:

   The external lists are queried, perhaps
   through a list-specific mechanism, and the test evaluates to "true"
   if any of the specified values matches any member of one or more of
   the lists.

And:

   When any value is found to belong to the
   list, the queries stop and the test returns "true".  If no value
   belongs to the list, the test returns "false".

If a test MUST return true if any value is found to belong to the list,
does that place a limit on the "list-specific mechanism" by which a list
can be queried? If so, it would be good to say that, and to describe a
bit more what we mean by list-specific mechanisms. (It's also not clear
to me how such list-specific mechanisms are discovered or advertised.)

Section 2.4 states:

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

URLs, or URIs?

IMHO it would be helpful for Section 2.5 to provide more examples.

Section 4 seems to imply that this document is registering a notify
Sieve extension per RFC 5435, but as far as I can see the extlists
extension is not a notification method.

Section 4 mentions both the ':list' match type and the ':list' argument
for the 'redirect' action. Are there (or could there be) any other uses
for the extlists extension?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2010 02:38:00 -0400

> to me how such list-specific mechanisms are discovered or advertised.)

There's no reason for it to be either discovered or advertised.  The
point of talking about a "list-specific mechanism" is exactly that
it's opaque, so no assumptions can be made about how it works.  It's
not done with a Sieve comparison.

The "queries stop" bit was meant as a way to say that once a match is
found, the list-specific mechanism needn't keep looking at the other
values.  If you think it's useful, I can change the text to say that.
Perhaps:

    If any value is found to belong to the list, the test returns
"true".  If no value
    belongs to the list, the test returns "false".  Once a value is
found in the list,
    there is no need for the query mechanism to look further.

>   [TAG-URI] to be useful for naming external lists.

Fixed; thanks.

> IMHO it would be helpful for Section 2.5 to provide more examples.

More examples are always good.  If anyone can give me specific
examples, I'll put them in.  Unless there are implementations of this,
I don't know that we have good examples to give.

> extension is not a notification method.

No, this document is registering a Sieve extension, per RFC 5228.
It's just the word "notify" that's extraneous, and I've removed it.

> for the extlists extension?

There aren't any we've thought of.  Do you have anything in mind?
I suppose one could come up with a use case for having the target of
"fileinto" come from a list, or something like that.  But (1) no one's
seen a need for that yet, and (2) it's always possible to extend this
extension in future.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 08:28:50 -0600

>     there is no need for the query mechanism to look further.

I think that's better. Off the top of my head I can't come up with a
list-specific mechanism that might continue processing after finding a
match, but that seems like a matter of implementation and not something
that needs a MUST in the spec.

> I don't know that we have good examples to give.

Sorry, I don't have examples to give, but the title of that section is
"Examples" so I was hoping for more than one. ;-)

> seen a need for that yet, and (2) it's always possible to extend this

I do think it would be helpful to say somewhere (perhaps in Section 2 or
2.1) that the use cases in this document are not exhaustive and that the
extlists capability could be used for other Sieve features in the future.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Sep 2010 14:58:11 -0400

> "Examples" so I was hoping for more than one. ;-)

This is a call to other WG participants:
Please give me a couple of specific examples to add to the document.
Unless Peter wants to hold the document up for this, I won't hold it
up waiting, either.  But we'd both *really* like a couple more
examples.

> extlists capability could be used for other Sieve features in the future.

I have added the following between sections 2.3 and 2.4.  WFY ?

          <section anchor="other-uses" title='Other uses for external lists'>
            <t>
              The uses for external lists specified here represent the useful
              cases and situations at the time of this writing.
              Other uses for external lists, using other Sieve features,
              might be devised in the future, and such uses can be
              described in extensions to this document.
            </t>
          </section>

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 14:23:48 -0600

On 9/30/10 12:58 PM, Barry Leiba wrote:
> Unless Peter wants to hold the document up for this, 

I shan't.

> I won't hold it

WFM, thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/