Subject: 3028bis open issue #1: envelope-sender argument for redirect?

From: Philip Guenther <[email-masked]>
Date: Wed, 29 Jun 2005 01:19:46 -0700

There was a suggestion that the 'redirect' action should provide a
way to specify the envelope-from address used when the message was
redirected.

While a nice idea, no one has said anything further on it, which
says to me that we shouldn't add it as a new requirement on
implementations.

I'm therefore removing this item from the open-issues list; if
someone wants that control they should write up an extension that
adds it.

Philip Guenther

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 30 Jun 2005 17:02:31 -0400

> says to me that we shouldn't add it as a new requirement on

Up until you posted, there wasn't much discussion on any of the 3 items
you emailed about separately, so I don't know if that conclusion follows
from that justification.  I suspect it's a correct conclusion though :-)

OTOH, I'm probably being dumb again (feel free to agree), but what's the
meta-stuff?  i.e.  how has 3028bis come about, what's the charter for
its creation, is there a call for submissions of items, etc?

mm

---

From: Philip Guenther <[email-masked]>
Date: Thu, 30 Jun 2005 17:59:02 -0700

Mark E. Mallett <[email-masked]> writes:
...
>its creation, is there a call for submissions of items, etc?

http://www.ietf.org/html.charters/sieve-charter.html

	(1) Revise the base sieve specification, RFC 3028, with the
	intention of moving it to draft standard. Substantive
	additions or revisions to the base specification are out
	of scope of this working group. However, the need to loosen
	current restrictions on side effects of tests as well as
	the need for a normative reference to the newly-defined
	comparators registry may necessitate a recycle at proposed.

With the comparator and side-effects bits done, we should be down
to corrections of errors and clarifications, right?

So, I see I was in error to even consider the 'add option to set
envelope-sender' suggestion as an open issue, as it's out of scope.
Similarly, changing section 2.7.2 to require support for 2047 should
be considered out of scope as well.

Hmm, perhaps we can last call this thing just before IETF-63.

Philip Guenther