Subject: [sieve] SIEVE WG Status

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Jun 2011 11:07:52 -0400

Hi folks,
I wanted to give a status update of the WG and also ask a few questions of 
everyone to see where we want to go. This comes at the prompting of our new 
AD who wants to judge the "energy level" of this WG to determine whether it 
makes sense for the WG to continue.

Note that I did request a 1 hour session for the upcoming meeting in Quebec 
City

The last face-to-face WG meeting was last July. Since then the following 
drafts have been through IETF processing and are now in the RFC editor 
queue:

draft-ietf-sieve-autoreply
draft-ietf-sieve-external-lists
draft-ietf-sieve-notify-presence
draft-ietf-sieve-vacation-seconds

These should all be published soon (having mostly been blocked on 
external-lists which was recently approved). Thanks to everyone for their 
work on these.

There has been a WG last call on the draft-ietf-sieve-include document and 
an update to that will be available very shortly so that we can continue 
with IETF processing of that.

All our other drafts are currently expired. From our charter, here are the 
outstanding items that have previous had drafts published:

   (1) Finish work on existing in-progress Working Group documents:
       (b) Notify SIP (draft-ietf-sieve-notify-sip-message)
       (c) RegEx (draft-ietf-sieve-regex)
       (e) Sieve in IMAP (draft-ietf-sieve-imap-sieve)

   (2) Finalize and publish the following SIEVE extensions as proposed
   standards:
       (d) Convert messages (draft-melnikov-sieve-convert)

Can the authors of these documents please provide a status update and 
indicate whether they intend to continue work on them? Can we also have 
other people comment on whether they intend to implement, or at least 
review or help with, any of these drafts?

If the WG does shut down, it seems reasonable for any of these drafts to 
continue on as individual contributions.

At the very least, if we are going to continue work on them I would like to 
see updates published in time for discussion at the IETF meeting (July 11th 
cut-off for draft submission).

We have a bunch of other items on our charter which I have listed below 
with some of my own comments on what I think should happen with them. 
Please comment on these yourselves so we can decide whether to continue or 
drop these from the charter if we decide the WG should continue on.

   (3) Work on a specification for iCalendar and vCard extraction, and
   cooperate with the VCARDDAV WG for address book tests in Sieve.

I suspect I might have been one of the primary movers for this particular 
topic, but at this point I don't it is relevant any more. So I would be in 
favor of dropping this.

   (4) Work on a specification to describe how EAI/IDN issues should be
   handled in SIEVE.

We have periodically asked about this, and most of the time there seemed 
very little that needed to be done in SIEVE to deal with this. One option 
going forward is for the WG to drop this item in favor of it being picked 
up in the EAI WG.

   (5) Work on a "Benefits of SIEVE" guide for client and server vendors
  that:
       (a) Describes the SIEVE protocol and its suite of extensions.
       (b) Explains the benefits of server-side filtering in practical 
terms.
       (c) Shows how client-side filtering can be migrated to SIEVE.

Whilst there was a lot of initial enthusiasm for this when we originally 
did a re-charter, there has been no progress in developing a document. At 
this point I would propose we drop this from the charter.

   (6) Produce one or more informational RFCs containing a set of test
   scripts and test email messages that are to be filtered by the scripts,
   and the expected results of that filtering. This will serve as the basis
   of a interoperability test suite to help determine the suitability of
   moving the base specification and selected extensions to Draft status.

Again there was initial enthusiasm for this, but nothing has materialized, 
so I would also propose dropping this from the charter.

Next question: does anyone have any new SIEVE work they would like to 
propose at this time?

I don't think anyone can deny this WG has been successful over the years in 
addressing the needs of SIEVE implementations, even if at our own, 
sometimes slow, pace. Shutting it down now would not be unreasonable, but I 
think we do need to prove the utility of keeping it alive. So please chime 
in with your thoughts.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Jun 2011 13:59:42 -0400

Hi, Cyrus, and thanks for the update.

> external-lists which was recently approved). Thanks to everyone for their

We can actually ask the ADs to release the hold on the three earlier
drafts.  They were not actually waiting on a normative reference to
external-lists.  It was an AD-requested hold to make sure that the
external-lists URI questions were settled down so that the examples
would be correct.  Now that external-lists is in the RFC-ed queue, the
other three docs can go ahead.  I'm copying Pete, asking him to ask
the RFC Editor to go ahead and process autoreply, notify-presence, and
vacation-seconds, and I will correct the examples in AUTH48.

>      (d) Convert messages (draft-melnikov-sieve-convert)

For (b) and (d), one of the authors (Sun Qian from Huawei) now has
other responsibilities.  My Huawei colleague Kepeng Li and I have
taken over his part of the work, and Kepeng has done an update on them
both.  We're now waiting for me to do a pass on them, which I expect
to get to this week or next.  So these will soon have a new version,
and we can finish them up.

For (e), I have an almost-ready version that's been almost ready for a
while.  I will finish it up and submit it after I get the
aforementioned two done, so expect it, also, within the next two
weeks.  It should address all of Ned's comments from the last round of
reviews, and so it should be pretty close to being a finished
version... I hope.

>  cooperate with the VCARDDAV WG for address book tests in Sieve.

External-lists probably does all we really need for address book
tests, and I agree with dropping this one.

>  (4) Work on a specification to describe how EAI/IDN issues should be

I don't really see EAI picking this up, but I think there isn't much,
if anything, that needs to be done, and we can address it later,
either in the working group (if it hadn't been closed by then) or as
an individual submission.

>  (5) Work on a "Benefits of SIEVE" guide for client and server vendors

I agree with dropping this, unless someone can get a reasonable first
draft put together before Québec.

>  moving the base specification and selected extensions to Draft status.

It seems to me that no one thinks it's important to move the base spec
to DS.  In any case, the huge number of extensions makes it seem a bit
pointless to move base to DS by itself, without bringing a suite of
the most useful/important extensions with it, and that's not happening
soon, I don't think.  Yes, let's drop this.

> Next question: does anyone have any new SIEVE work they would like to

I think we have what we need, and we should wrap up what we're doing,
declare success, and drink lots of beer.  (That said, I don't think
there's a need to hurry to close it without finishing the work in
progress, and (except perhaps for RegEx) we will soon finish it.  I
should say we'd have the remaining open docs (except perhaps for
RegEx) to the IESG by the end of August.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Jun 2011 14:00:24 -0400

> vacation-seconds, and I will correct the examples in AUTH48.

But, of course, I forgot to copy Pete.  Doing that this time.

Barry

---

From: Likepeng <[email-masked]>
Date: Tue, 21 Jun 2011 01:19:54 +0000

>That said, I don't think there's a need to hurry to close it without finishing the work in

+1. We are working hard offline for the remaining drafts (b, d, e).

Thanks,
Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Tuesday, June 21, 2011 2:00 AM
To: Cyrus Daboo
Cc: SIEVE
Subject: Re: [sieve] SIEVE WG Status

Barry
_______________________________________________
sieve mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sieve

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 21 Jun 2011 03:25:18 +0200

Hi,

On 6/20/2011 5:07 PM, Cyrus Daboo wrote:
> I don't think anyone can deny this WG has been successful over the 
> years in addressing the needs of SIEVE implementations, even if at our 
> own, sometimes slow, pace. Shutting it down now would not be 
> unreasonable, but I think we do need to prove the utility of keeping 
> it alive. So please chime in with your thoughts.
>

There is one thing I've noticed: the more user-friendly GUIs and web 
interfaces allow users to edit Sieve scripts as a set of intuitive 
(structurally pre-defined) mail filter rules. This avoids the need to 
learn Sieve and write detailed Sieve scripts directly, which can be 
daunting for the less capable mail user. However, Sieve has no real 
concept of a `mail filter rule', so a translation is necessary from the 
rules defined in the editor and the Sieve script on the server. Also, a 
convention is to name the mail filters to provide an indication of their 
purpose. Other forms of such metadata are imaginable, such as creation 
date, name of the creating software etc.

The problem is that such data needs to be stored somewhere. Some 
solutions involve storing the metadata along with the rules themselves 
in a database or another form of storage external to Sieve. The Sieve 
script is then created from this storage once the rules change. On the 
one hand, this avoids the complexity of parsing Sieve scripts to regain 
access to the original rules and metadata, but, on the other hand, it 
completely blocks using multiple different interfaces for editing the 
same Sieve scripts. Direct changes to the Sieve scripts would simply be 
lost once the rules change.

Alternatively, some script generators encode such metadata in Sieve 
comments and parse the Sieve script itself to extract the rules. This 
way, the Sieve script itself is the only  means of storage, 
theoretically allowing multiple distinct Sieve generators (GUIs and web 
interfaces) to inter-operate with the same Sieve scripts. Unfortunately, 
I've seen little or no coordination between the script generator 
authors, which probably means that scripts generated by one interface 
cannot be edited through an alternative one, mostly because the encoded 
comments are going to be incompatible. Of course, the Sieve code itself 
can also be incompatible if the Sieve generators don't support the same 
set of Sieve features or if some code structure is not recognized. 
However, I think this could be mended quite easily by presenting rules 
that cannot be handled by the GUI itself as custom or external; not to 
be touched by that particular interface.

The main requirement would be that individual rules in the script can be 
annotated with a name and that a parsing GUI can distinguish where rules 
begin and end. A standardized means to achieve this could, in my 
opinion, increase interoperability between Sieve script generators.

However, I have only implemented a Sieve interpreter so far (which 
obviously doesn't care about metadata encoded in comments) and I 
therefore have no experience with Sieve GUIs and web interfaces and the 
complexities involved. I haven't seen much discussion about this subject 
and I am wondering whether this is currently perceived as a concern at 
all. I vaguely remember a short discussion about this in a thread 
related to Sieve in XML, but nothing else.

Are users expected to use only one interface/method for editing their 
(active) scripts? Would it be useful to provide a specification on how 
to encode meta-data in Sieve script comments?

Regards,

Stephan.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Jun 2011 11:17:17 -0500

> vacation-seconds, and I will correct the examples in AUTH48.

Pete acks.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 21 Jun 2011 22:57:15 +0100

> Hi folks,

Hi Cyrus,

> I wanted to give a status update of the WG and also ask a few 
> questions of everyone to see where we want to go. This comes at the 
> prompting of our new AD who wants to judge the "energy level" of this 
> WG to determine whether it makes sense for the WG to continue.
>
> Note that I did request a 1 hour session for the upcoming meeting in 
> Quebec City
>
> The last face-to-face WG meeting was last July. Since then the 
> following drafts have been through IETF processing and are now in the 
> RFC editor queue:
>

> draft-ietf-sieve-vacation-seconds

I think these drafts were past AUTH48 when I stopped them from being 
published (due to the reference to draft-ietf-sieve-external-lists). So 
the RFC Editor should be told that we want to review/fix examples before 
publishing.

> external-lists which was recently approved). Thanks to everyone for 
> their work on these.
>
> There has been a WG last call on the draft-ietf-sieve-include document 
> and an update to that will be available very shortly so that we can 
> continue with IETF processing of that.
>
> All our other drafts are currently expired. From our charter, here are 
> the outstanding items that have previous had drafts published:
>

I am particularly interested in (c) and (e) at this point. I would 
really appreciate somebody showing interest in (b) and (d).

> indicate whether they intend to continue work on them? Can we also 
> have other people comment on whether they intend to implement, or at 
> least review or help with, any of these drafts?
>
> If the WG does shut down, it seems reasonable for any of these drafts 
> to continue on as individual contributions.

Does our esteemed AD agree?

> At the very least, if we are going to continue work on them I would 
> like to see updates published in time for discussion at the IETF 
> meeting (July 11th cut-off for draft submission).
>
> We have a bunch of other items on our charter which I have listed 
> below with some of my own comments on what I think should happen with 
> them. Please comment on these yourselves so we can decide whether to 
> continue or drop these from the charter if we decide the WG should 
> continue on.
>
> I suspect I might have been one of the primary movers for this 
> particular topic, but at this point I don't it is relevant any more. 
> So I would be in favor of dropping this.

My idea behind this was to have a test that can reach inside XML body 
parts, possibly using XPath or similar.

> We have periodically asked about this, and most of the time there 
> seemed very little that needed to be done in SIEVE to deal with this. 
> One option going forward is for the WG to drop this item in favor of 
> it being picked up in the EAI WG.

I declare this to be Pete's problem either way ;-).
Doing this in EAI would be fine.

> Whilst there was a lot of initial enthusiasm for this when we 
> originally did a re-charter, there has been no progress in developing 
> a document. At this point I would propose we drop this from the charter.

With some sadness, I have to agree.

> Again there was initial enthusiasm for this, but nothing has 
> materialized, so I would also propose dropping this from the charter.

Right.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Jun 2011 17:11:37 -0500

On 6/21/11 4:57 PM, Alexey Melnikov wrote:
> published (due to the reference to draft-ietf-sieve-external-lists). 
> So the RFC Editor should be told that we want to review/fix examples 
> before publishing.

They are all showing in "EDIT" now. But I already let the RFC Editor 
know that they are no longer on AD hold, so you may want to email them 
to check on status.

> Does our esteemed AD agree?

Your humble and curmudgeonly AD is going to ask lots of questions about 
what kind of review (both small and IETF-wide) these documents are going 
to get before he is thrilled out of his mind to take them on as 
individual submissions through the AD and declare them "consensus 
documents". If you can't generate interest in getting them reviewed in a 
WG, I'm not entirely convinced how you're going to get enough review 
without one. And I hate dealing with individual submission documents, 
especially if I've got to do all of the legwork to get them reviewed.

> Doing this in EAI would be fine.

Let's start by making it Klensin's and Yee's problem if it comes to 
that. They can make it my problem in due time.

pr

---

From: [email-masked]
Date: Wed, 22 Jun 2011 10:54:05 -0700 (PDT)

> date, name of the creating software etc.

The base Sieve language may not have these constructs (and IMO should not), but
that doesn't mean they haven't been defined. See RFC 5784.

> comments and parse the Sieve script itself to extract the rules.

This is the approach taken in RFC 5784. Note that the format is defined for
both the XML form and native form of Sieve, as well as the rules for converting
between the two.

> This
> comments are going to be incompatible.

Yes, this is a problem, and it partially addressed in RFC 5784: Structuring
conventions are defined so that at least the basic rule structure can be
shared. But sharing of specific rule semantics is a lot trickier.

> Of course, the Sieve code itself

RFC 5463 provides some solutions for these issues.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Jun 2011 16:38:17 -0400

>> published (due to the reference to draft-ietf-sieve-external-lists). So the
>> RFC Editor should be told that we want to review/fix examples before
>> publishing.
>
> They are all showing in "EDIT" now. But I already let the RFC Editor know
> that they are no longer on AD hold, so you may want to email them to check
> on status.

So emailed.

> Your humble and curmudgeonly AD is going to ask lots of questions about what
> kind of review (both small and IETF-wide) these documents are going to get
> before he is thrilled out of his mind to take them on as individual
> submissions through the AD and declare them "consensus documents". If you
> can't generate interest in getting them reviewed in a WG, I'm not entirely
> convinced how you're going to get enough review without one. And I hate
> dealing with individual submission documents, especially if I've got to do
> all of the legwork to get them reviewed.

I agree with Pete: we should make every effort to keep the WG open to
work on them.  If we can't do that, then we clearly don't have enough
interest to do them outside the WG.  In that case, they could go to
the ISE, and come out as informational, describing a planned
standardization that didn't happen.

I hope it doesn't come to that, and that we can have enough enthusiasm
left to finish them here.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 23 Jun 2011 11:33:07 +0200

> that doesn't mean they haven't been defined. See RFC 5784.

Damn, now why did I miss this part? Yes, RFC 5784 pretty much covers 
most of the issue. Apparently, it has been a while since I last read this.

Sorry for the noise.

Regards,

Stephan.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Jun 2011 11:09:44 -0400

Hi ,
After consultation with our AD, the current plan is to go ahead with the 
meeting in Quebec City next month. However, the level of activity/interest 
in on going work expressed at that meeting (and in the intervening time) 
will be used to determine whether we continue with a Working Group or shut 
it down in favor of individual submissions.

Please submit updates to all drafts that you would like to see discussed in 
Quebec, and post a list of discussion items for those (so I can start to 
put together an agenda). Note we only have a 1 hour slot so we need to 
concentrate on key issues that need "face time" discussions.

-- 
Cyrus Daboo