draft-martin-sieve-notify-01.txt

[Jutta Degener <[e-mail]>]

Hi!  I've just read the sieve-notify-01 draft closely for the first time.
Here are some questions and comments.

Meta:
      - It has expired, and I notice that there were some discussions on the 
	mailing list last July and a promise of a new version soon -- what is
	its status now?

      - The draft's header lists the title incorrectly as
        <draft-ietf-sieve-notify-01.txt>.

3.1 Notify action

      - I'd have expected an IANA registry that lists and fixes the
        methods and options and corresponding require: tags.

        Having these implementation-defined features without a way
        of verifying them makes me uneasy.

	Everything else in sieve is quite predictable; scripts as a whole
	either fail because they use unimplemented features or have well-defined
	meaning -- and here, all of a sudden, is this big, powerful,
	implementation-defined area that sends out messages that sometimes
	costs money without the author being able to automate verification
	that what they think a script means actually means it.

      -	> The format of the notification is implementation-defined.
        > However, all content specified in the notify action, including Sieve
	> actions taken on the message, SHOULD be included.

	If I understand this correctly, you would like the notification to
	include a complete log of the sieve actions taken on the message, which 
	goes beyond "the content specified in the notify action"; it would
	also include pieces of sieve script before and after the line that
	issues the notification.  Right?

      - > If errors occurred in another action they SHOULD be reported
	> in the notification.
	And later:
	> Failures of other actions MAY be reported in the notification.

	This is in direct conflict with a rule in the sieve RFC 3028:

	> When an error occurs in a Sieve script, all processing stops.  [2.10.6]

Variables 

	- I would like $env-from$ (and related variables, if you add them)
	  defined with a reference to the sieve "envelope" operator, not to
	  RFC 2?821.  (The envelope used in sieve might not be an SMTP envelope.)
	
	- I strongly agree with the past discussion asking for more control
	  over the formatting and over which parts are chosen.

	- In practice, I think limiting the length even of $from$ (and its
	  related variables) and certainly of $subject$ would be a good thing.
	  (Alternatively, allow implementation-defined limits on these things. )

	  When I have completely free hand, I tend to truncate single-line
	  texts in the middle, like this:

	  	Subject: [mailing-list] This is a long ta ... cess and a frog.
	
	  It would be nice to be allowed to do this, but it's kind of
	  difficult to specify.  (Maybe something is truncated in an
	  implementation-defined manner to no more than N characters.)

	  In response to July's discussion of whether this should be
	  counting chars or bytes, for SMS, it only makes sense to count
	  output bytes, not chars, since the limits one is trying to fit
	  into are byte limits.

3.2 Denotify Action

      - This surprised me.  Couldn't generic sieve control structures be used
        to accomplish the same with fewer constructs and thus a simpler language?
	I'd hate to see a precedent set where other, future extensions, in addition
	to their specified action, also include an action-specific cancellation
	mechanism!

	I don't really have much experience with this mechanism; maybe it's handy
	if you write a lot, and complex, sieve scripts.  But this is supposed to
	be simple and small; I don't feel like this powerful mechanism fits that.

Thanks!,

Jutta Degener
<[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGqaX12357 for ietf-mta-filters-bks; Mon, 28 Jan 2002 08:52:36 -0800 (PST)
Received: from localhost.sendmail.com (toad-1635-17.dslbr.toad.net [162.33.201.17] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGqY312352 for <[e-mail]>; Mon, 28 Jan 2002 08:52:34 -0800 (PST)
Received: (from jutta@localhost) by localhost.sendmail.com (8.11.6/8.11.6) id g0SGpn609781 for [e-mail]; Mon, 28 Jan 2002 08:51:49 -0800
Date: Mon, 28 Jan 2002 08:51:49 -0800
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: draft-martin-sieve-notify-01.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi!  I've just read the sieve-notify-01 draft closely for the first time.
Here are some questions and comments.

Meta:
      - It has expired, and I notice that there were some discussions on the 
	mailing list last July and a promise of a new version soon -- what is
	its status now?

      - The draft's header lists the title incorrectly as
        <draft-ietf-sieve-notify-01.txt>.

3.1 Notify action

      - I'd have expected an IANA registry that lists and fixes the
        methods and options and corresponding require: tags.

        Having these implementation-defined features without a way
        of verifying them makes me uneasy.

	Everything else in sieve is quite predictable; scripts as a whole
	either fail because they use unimplemented features or have well-defined
	meaning -- and here, all of a sudden, is this big, powerful,
	implementation-defined area that sends out messages that sometimes
	costs money without the author being able to automate verification
	that what they think a script means actually means it.

      -	> The format of the notification is implementation-defined.
        > However, all content specified in the notify action, including Sieve
	> actions taken on the message, SHOULD be included.

	If I understand this correctly, you would like the notification to
	include a complete log of the sieve actions taken on the message, which 
	goes beyond "the content specified in the notify action"; it would
	also include pieces of sieve script before and after the line that
	issues the notification.  Right?

      - > If errors occurred in another action they SHOULD be reported
	> in the notification.
	And later:
	> Failures of other actions MAY be reported in the notification.

	This is in direct conflict with a rule in the sieve RFC 3028:

	> When an error occurs in a Sieve script, all processing stops.  [2.10.6]

Variables 

	- I would like $env-from$ (and related variables, if you add them)
	  defined with a reference to the sieve "envelope" operator, not to
	  RFC 2?821.  (The envelope used in sieve might not be an SMTP envelope.)
	
	- I strongly agree with the past discussion asking for more control
	  over the formatting and over which parts are chosen.

	- In practice, I think limiting the length even of $from$ (and its
	  related variables) and certainly of $subject$ would be a good thing.
	  (Alternatively, allow implementation-defined limits on these things. )

	  When I have completely free hand, I tend to truncate single-line
	  texts in the middle, like this:

	  	Subject: [mailing-list] This is a long ta ... cess and a frog.
	
	  It would be nice to be allowed to do this, but it's kind of
	  difficult to specify.  (Maybe something is truncated in an
	  implementation-defined manner to no more than N characters.)

	  In response to July's discussion of whether this should be
	  counting chars or bytes, for SMS, it only makes sense to count
	  output bytes, not chars, since the limits one is trying to fit
	  into are byte limits.

3.2 Denotify Action

      - This surprised me.  Couldn't generic sieve control structures be used
        to accomplish the same with fewer constructs and thus a simpler language?
	I'd hate to see a precedent set where other, future extensions, in addition
	to their specified action, also include an action-specific cancellation
	mechanism!

	I don't really have much experience with this mechanism; maybe it's handy
	if you write a lot, and complex, sieve scripts.  But this is supposed to
	be simple and small; I don't feel like this powerful mechanism fits that.

Thanks!,

Jutta Degener
<[e-mail]>