Re: FW: "Unicode" vs "ISO 10646"

[Kjetil Torgrim Homme <[e-mail]>]

On Thu, 2005-10-27 at 13:01 -0400, Scott Hollenbeck wrote:
> Here's something to think about that came up during today's IESG evaluation
> of draft-ietf-sieve-variables.  It might be worth talking about since the
> doc needs some other edits before IESG approval.

> >>From: Brian E Carpenter [mailto:[e-mail]] 
> >>
> >>While scanning drafts in Frankfurt airport, I noticed
> >>that two of them (the iris and sieve drafts) refer in the
> >>text to Unicode.
> >>
> >>My understanding is that the IETF recommendation is to
> >>use the ISO 10646 coded character set, and I thought there
> >>were good reasons we specified that instead of Unicode.
> >>
> >>What should we be looking for in RFCs?
>>
>> Where is that recommendation?
>
> RFC 2277 = BCP 18
> 
> which doesn't even mention Unicode. (Also see RFC 2130).

on the other hand, stringprep (RFC 3454) is quite explicit in that it is
based on Unicode 3.2, rather than "ISO 10646 with amendments".  I
believe this is a more stringent choice, although I'm unsure if an
explicit reference to Unicode 3.2 is the right choice for miscellaneous
other documents.

I believe it would be very useful to define a stringprep profile for
Sieve.  the profile may be defined for more general usage (comparators
too, others?), but something [SIEVE] can refer to would make things a
whole lot clearer.  I don't suggest to make it mandatory for Sieve, but
*either* you support US-ASCII only (and use the identity mapping for
other code points) *or* you support the profile.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VHgPVH091198; Mon, 31 Oct 2005 09:42:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VHgPYQ091197; Mon, 31 Oct 2005 09:42:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VHgOdW091189 for <[e-mail]>; Mon, 31 Oct 2005 09:42:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EWdfo-0007K3-8n; Mon, 31 Oct 2005 18:42:20 +0100
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EWdfl-0004wz-Tn; Mon, 31 Oct 2005 18:42:17 +0100
Subject: Re: FW: "Unicode" vs "ISO 10646"
From: Kjetil Torgrim Homme <[e-mail]>
To: Scott Hollenbeck <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 31 Oct 2005 18:42:11 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.691, required 12, autolearn=disabled, AWL 1.12, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Thu, 2005-10-27 at 13:01 -0400, Scott Hollenbeck wrote:
> Here's something to think about that came up during today's IESG evaluation
> of draft-ietf-sieve-variables.  It might be worth talking about since the
> doc needs some other edits before IESG approval.

> >>From: Brian E Carpenter [mailto:[e-mail]] 
> >>
> >>While scanning drafts in Frankfurt airport, I noticed
> >>that two of them (the iris and sieve drafts) refer in the
> >>text to Unicode.
> >>
> >>My understanding is that the IETF recommendation is to
> >>use the ISO 10646 coded character set, and I thought there
> >>were good reasons we specified that instead of Unicode.
> >>
> >>What should we be looking for in RFCs?
>>
>> Where is that recommendation?
>
> RFC 2277 = BCP 18
> 
> which doesn't even mention Unicode. (Also see RFC 2130).

on the other hand, stringprep (RFC 3454) is quite explicit in that it is
based on Unicode 3.2, rather than "ISO 10646 with amendments".  I
believe this is a more stringent choice, although I'm unsure if an
explicit reference to Unicode 3.2 is the right choice for miscellaneous
other documents.

I believe it would be very useful to define a stringprep profile for
Sieve.  the profile may be defined for more general usage (comparators
too, others?), but something [SIEVE] can refer to would make things a
whole lot clearer.  I don't suggest to make it mandatory for Sieve, but
*either* you support US-ASCII only (and use the identity mapping for
other code points) *or* you support the profile.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VGhfdX086167; Mon, 31 Oct 2005 08:43:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VGhfTq086166; Mon, 31 Oct 2005 08:43:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VGhfBq086159 for <[e-mail]>; Mon, 31 Oct 2005 08:43:41 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.125] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 31 Oct 2005 16:43:36 +0000
Message-ID: <[e-mail]>
Date: Mon, 31 Oct 2005 16:43:36 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Material for the Sieve meeting in Vancouver
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

I would also like to know who is going to attend the meeting and who can 
participate in jabber.
Please send replies to me directly.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VAn5kE047725; Mon, 31 Oct 2005 02:49:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VAn5wJ047724; Mon, 31 Oct 2005 02:49:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VAn4Wu047717 for <[e-mail]>; Mon, 31 Oct 2005 02:49:05 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.136] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 31 Oct 2005 10:48:59 +0000
Message-ID: <[e-mail]>
Date: Mon, 31 Oct 2005 10:49:00 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Material for the Sieve meeting in Vancouver
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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 everybody,
I would like to request all editors to prepare and send me slides and/or 
short report on issues for each document they are editing.

Thanks,
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9TNHtxH078264; Sat, 29 Oct 2005 16:17:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9TNHtiu078263; Sat, 29 Oct 2005 16:17:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eastrmmtao04.cox.net (eastrmmtao04.cox.net [68.230.240.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9TNHrVY078250 for <[e-mail]>; Sat, 29 Oct 2005 16:17:54 -0700 (PDT) (envelope-from [e-mail])
Received: from A31P ([68.100.55.187]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051029231647.KQHH23022.eastrmmtao04.cox.net@A31P>; Sat, 29 Oct 2005 19:16:47 -0400
From: "Scott Hollenbeck" <[e-mail]>
To: "'Barry Leiba'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-sieve-3431bis-02
Date: Sat, 29 Oct 2005 19:17:47 -0400
Message-ID: <001901c5dcde$f9bfe380$2667fea9@A31P>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AcXcv2O7MkBbZVUQS+iapfooBWUAKwAH1oRA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
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>

> -----Original Message-----
> From: Barry Leiba [mailto:[e-mail]] 
> Sent: Saturday, October 29, 2005 3:30 PM
> To: [e-mail]
> Subject: draft-ietf-sieve-3431bis-02
> 
> Yes, well, Philip can say "I told you so."  The -02 draft was 
> bounced for not having the right boilerplate.  :-(  Anyway, I 
> spent this afternoon converting it to XML, so it will have it 
> all right.  I've attached the version that's produced by the 
> XML, and I'd like people to have a look and make sure I 
> didn't mess anything up, before I re-submit.

Barry, you might find this little tool helpful:

http://ietf.levkowetz.com/tools/idnits/

It does most of the checking for you.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9TJUU1p056762; Sat, 29 Oct 2005 12:30:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9TJUUpZ056761; Sat, 29 Oct 2005 12:30:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9TJUSl5056752 for <[e-mail]>; Sat, 29 Oct 2005 12:30:29 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9TJWGiL010885 for <[e-mail]>; Sat, 29 Oct 2005 15:32:16 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9TJUMF322986 for <[e-mail]>; Sat, 29 Oct 2005 15:30:22 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9TJUL4322984 for <[e-mail]>; Sat, 29 Oct 2005 15:30:22 -0400
Received: from SATURN ([9.12.242.186]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1130614221.333; Sat, 29 Oct 2005 15:30:21 -0400
Date: Sat, 29 Oct 2005 15:30:20 -0400
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: draft-ietf-sieve-3431bis-02
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========95FB3F64BB73E91E086D=========="
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>

--==========95FB3F64BB73E91E086D==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Yes, well, Philip can say "I told you so."  The -02 draft was bounced
for not having the right boilerplate.  :-(  Anyway, I spent this
afternoon converting it to XML, so it will have it all right.  I've
attached the version that's produced by the XML, and I'd like people to
have a look and make sure I didn't mess anything up, before I re-submit.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

--==========95FB3F64BB73E91E086D==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-sieve-3431bis-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-sieve-3431bis-02.txt";
 size=18319




Sieve Working Group                                         W. =
Segmuller
Internet-Draft                                                  B. =
Leiba
Obsoletes: 3431 (if approved)            IBM T.J. Watson Research =
Center
Expires: May 2, 2006                                    October 29, =
2005


                   Sieve Extension: Relational Tests
                      draft-ietf-sieve-3431bis-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields.

Note




Segmuller & Leiba          Expires May 2, 2006                  [Page =
1]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


   This document is intended to be an update to the existing
   "relational" extension to the Sieve mail filtering language,
   available from the RFC repository as
   ftp://ftp.isi.edu/in-notes/rfc3431.txt.

   This document and the Sieve language itself are being discussed on
   the MTA Filters mailing list at mailto:[e-mail].
   Subscription requests can be sent to
   mailto:[e-mail]?body=3Dsubscribe (send an =
email
   message with the word "subscribe" in the body).  More information on
   the mailing list along with a WWW archive of back messages is
   available at http://www.imc.org/ietf-mta-filters/.

Table of Contents

   1.   Conventions used in this document  . . . . . . . . . . . . .   =
3

   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   =
4

   3.   Comparators  . . . . . . . . . . . . . . . . . . . . . . . .   =
5

   4.   Match Types  . . . . . . . . . . . . . . . . . . . . . . . .   =
6
   4.1  Match Type VALUE . . . . . . . . . . . . . . . . . . . . . .   =
6
   4.2  Match Type COUNT . . . . . . . . . . . . . . . . . . . . . .   =
6

   5.   Interaction With Other Sieve Actions . . . . . . . . . . . .   =
8

   6.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .   =
9

   7.   Extended Example . . . . . . . . . . . . . . . . . . . . . .  =
10

   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  =
11

   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  =
12

   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  =
13
   10.1 Normative References . . . . . . . . . . . . . . . . . . . .  =
13
   10.2 Non-Normative References . . . . . . . . . . . . . . . . . .  =
13

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  =
13

        Intellectual Property and Copyright Statements . . . . . . .  =
14









Segmuller & Leiba          Expires May 2, 2006                  [Page =
2]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119.

   Conventions for notations are as in [Sieve] section 1.1, including
   the use of [Kwds] and "Syntax:" label for the definition of action
   and tagged arguments syntax, and the use of [ABNF].










































Segmuller & Leiba          Expires May 2, 2006                  [Page =
3]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


2.  Introduction

   [Sieve] is a language for filtering e-mail messages at the time of
   final delivery.  It is designed to be implementable on either a mail
   client or mail server.  It is meant to be extensible, simple, and
   independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Messages Access Protocol (IMAP) servers, as it has no
   variables, loops, nor the ability to shell out to external programs.

   The RELATIONAL extension provides relational operators on the
   address, envelope, and header tests.  This extension also provides a
   way of counting the entities in a message header or address field.

   With this extension, the sieve script may now determine if a field =
is
   greater than or less than a value instead of just equivalent.  One
   use is for the x-priority field: move messages with a priority
   greater than 3 to the "work on later" folder.  Mail could also be
   sorted by the from address.  Those userids that start with 'a'-'m' =
go
   to one folder, and the rest go to another folder.

   The sieve script can also determine the number of fields in the
   header, or the number of addresses in a recipient field.  For
   example: are there more than 5 addresses in the to and cc fields.

   The capability string associated with the extension defined in this
   document is "relational".























Segmuller & Leiba          Expires May 2, 2006                  [Page =
4]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


3.  Comparators

   This document does not define any comparators or exempt any
   comparators from the require clause.  Any comparator used must be
   treated as defined in [Sieve].

   The "i;ascii-numeric" comparator, as defined in [Comp], MUST be
   supported for any implementation of this extension.  The comparator
   "i;ascii-numeric" MUST support at least 32 bit unsigned integers.

   Larger integers MAY be supported.  Note: the "i;ascii-numeric"
   comparator does not support negative numbers.







































Segmuller & Leiba          Expires May 2, 2006                  [Page =
5]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


4.  Match Types

   This document defines two new match types.  They are the VALUE match
   type and the COUNT match type.

   The syntax is:

   MATCH-TYPE =3D/ COUNT / VALUE

   COUNT =3D ":count" relational-match

   VALUE =3D ":value" relational-match

   relational-match =3D DQUOTE
           ("gt" / "ge" / "lt" / "le" / "eq" / "ne") DQUOTE
           ; "gt" means "greater than", the C operator ">".
           ; "ge" means "greater than or equal", the C operator ">=3D".
           ; "lt" means "less than", the C operator "<".
           ; "le" means "less than or equal", the C operator "<=3D".
           ; "eq" means "equal to", the C operator "=3D=3D".
           ; "ne" means "not equal to", the C operator "!=3D".


4.1  Match Type VALUE

   The VALUE match type does a relational comparison between strings.

   The VALUE match type may be used with any comparator which returns
   sort information.

   A value from the message is considered the left side of the =
relation.
   A value from the test expression, the key-list for address, =
envelope,
   and header tests, is the right side of the relation.

   If there are multiple values on either side or both sides, the test
   is considered true if any pair is true.

4.2  Match Type COUNT

   The COUNT match type first determines the number of the specified
   entities in the message and does a relational comparison of the
   number of entities, as defined below to the values specified in the
   test expression.

   The COUNT match type SHOULD only be used with numeric comparators.

   The Address Test counts the number of addresses (the number of
   "mailbox" elements, as defined in [RFC2822]) in the specified =
fields.



Segmuller & Leiba          Expires May 2, 2006                  [Page =
6]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


   Group names are ignored, but the contained mailboxes are counted.

   The Envelope Test counts the number of addresses in the specified
   envelope parts.  The envelope "to" will always have only one entry,
   which is the address of the user for whom the sieve script is
   running.  There is no way a sieve script can determine if the =
message
   was actually sent to someone else using this test.  The envelope
   "from" will be 0 if the MAIL FROM is empty, or 1 if MAIL FROM is not
   empty.

   The Header Test counts the total number of instances of the =
specified
   fields.  This does not count individual addresses in the "to", "cc",
   and other recipient fields.

   In all cases, if more than one field name is specified, the counts
   for all specified fields are added together to obtain the number for
   comparison.  Thus, specifying ["to", "cc"] in an address COUNT test,
   compares the total number of "to" and "cc" addresses; if separate
   counts are desired, they must be done in two comparisons, perhaps
   joined by "allof" or "anyof".































Segmuller & Leiba          Expires May 2, 2006                  [Page =
7]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


5.  Interaction With Other Sieve Actions

   This specification adds two match types.  The VALUE match type only
   works with comparators that return sort information.  The COUNT =
match
   type only makes sense with numeric comparators.

   There is no interaction with any other Sieve operations, nor with =
any
   known extensions.  In particular, this specification has no effect =
on
   implicit KEEP, nor on any explicit message actions.










































Segmuller & Leiba          Expires May 2, 2006                  [Page =
8]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


6.  Example

   Using the message:

      received: ...
      received: ...
      subject: example
      to: [e-mail], [e-mail]
      cc: [e-mail]

   The test:

      address :count "ge" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["3"]

   would evaluate to true and the test

      anyof ( address :count "ge" :comparator "i;ascii-numeric"
                      ["to"] ["3"],
              address :count "ge" :comparator "i;ascii-numeric"
                      ["cc"] ["3"] )

   would evaluate to false.

   To check the number of received fields in the header, the following
   test may be used:

      header :count "ge" :comparator "i;ascii-numeric"
                      ["received"] ["3"]

   This would evaluate to false.  But

      header :count "ge" :comparator "i;ascii-numeric"
                      ["received", "subject"] ["3"]

   would evaluate to true.

   The test:

      header :count "ge" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["3"]

   will always evaluate to false on an RFC 2822 compliant message
   [RFC2822], since a message can have at most one "to" field and at
   most one "cc" field.  This test counts the number of fields, not the
   number of addresses.





Segmuller & Leiba          Expires May 2, 2006                  [Page =
9]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


7.  Extended Example

      require ["relational", "comparator-i;ascii-numeric", "fileinto"];

      if header :value "lt" :comparator "i;ascii-numeric"
                ["x-priority"] ["3"]
      {
         fileinto "Priority";
      }

      elsif address :count "gt" :comparator "i;ascii-numeric"
                 ["to"] ["5"]
      {
         # everything with more than 5 recipients in the "to" field
         # is considered SPAM
         fileinto "SPAM";
      }

      elsif address :value "gt" :all :comparator "i;ascii-casemap"
                 ["from"] ["M"]
      {
         fileinto "From N-Z";
      } else {
         fileinto "From A-M";
      }

      if allof ( address :count "eq" :comparator "i;ascii-numeric"
                         ["to", "cc"] ["1"] ,
                 address :all :comparator "i;ascii-casemap"
                         ["to", "cc"] ["[e-mail]"] )
      {
         fileinto "Only me";
      }


















Segmuller & Leiba          Expires May 2, 2006                 [Page =
10]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


8.  IANA Considerations

   This document requests that the IANA update the entry for the
   "relational" Sieve extension to point to this document.















































Segmuller & Leiba          Expires May 2, 2006                 [Page =
11]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


9.  Security Considerations

   An implementation MUST ensure that the test for envelope "to" only
   reflects the delivery to the current user.  It MUST not be possible
   for a user to determine if this message was delivered to someone =
else
   using this test.

   Additional security considerations are discussed in [Sieve].











































Segmuller & Leiba          Expires May 2, 2006                 [Page =
12]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


10.  References

10.1  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for =
Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [Kwds]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [Sieve]    Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", I-D draft-ietf-sieve-3028bis, July 2005.

10.2  Non-Normative References

   [Comp]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
           Application Protocol Collation Registry",
           I-D draft-newman-i18n-comparator, September 2005.


Authors' Addresses

   Wolfgang Segmuller
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: [phone]
   Email: [e-mail]


   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: [phone]
   Email: [e-mail]








Segmuller & Leiba          Expires May 2, 2006                 [Page =
13]
=0C
Internet-Draft      Sieve Extension: Relational Tests       October =
2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Segmuller & Leiba          Expires May 2, 2006                 [Page =
14]
=0C

--==========95FB3F64BB73E91E086D==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9S9sOWh047264; Fri, 28 Oct 2005 02:54:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9S9sOVP047263; Fri, 28 Oct 2005 02:54:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9S9sNph047256 for <[e-mail]>; Fri, 28 Oct 2005 02:54:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 28 Oct 2005 10:54:14 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Oct 2005 10:54:14 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: IESG review of draft-ietf-sieve-variables-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>>Subject: 	discuss: draft-ietf-sieve-variables
>>Date: 	Wed, 26 Oct 2005 14:41:34 -0400 (EDT)
>>From: 	Sam Hartman <[e-mail]>
>>
>>The :lower and :upper and other case-folding modifiers to the set
>>action do not seem to have a well defined case mapping for
>>internationalization.  It is true that the ACAP i;ascii-casemap does
>>define a case folding table for part of Unicode.  However I don't
>>understand how that's generally true or how consulting a comparator
>>will tell me which locale to use.
>>
>>Please provide information on how the four ACAP comparator operations
>>can be consulted to determine how to map case.  Alternatively, provide
>>another solution or extend the definition of ACAP comparator
>>sufficiently to meet your needs.
>>    
>>
>
>this is indeed the weakest part of the variables spec, I admit the use
>of a comparator with SET is little more than handwaving to appease the
>i18n concious :-).  the text is even careful to avoid implying that the
>comparator _has_ such a mechanism:
>
>        The comparator specified SHOULD be consulted to establish which
>        locale to use.
>
>"consulted" isn't very normative.  it was a trick, and Sam caught me.  I
>had hoped this would slide, and later we could fix up comparators
>"properly" by adding two new operations (upper case and lower case).
>however, such operations can hardly be called comparisons, and they're
>unary, not binary, so it's probably not such a hot idea.
>  
>
Indeed. Let's not call it "comparator".

>another option is to leave out the whole comparator thing, and just say
>(as it does already) that US-ASCII MUST be supported.  after all, all
>strings in Sieve are UTF-8 encoded characters from the ISO 10646
>repertoire anyway, so by not saying anything about it, we make it a
>quality of implementation issue.  which it would be, _anyway_.
>  
>
I think it is the quickest way to address the issue. Besides, one can 
document/implement something like ":upper_cyrillic" modifier.

>(at the same time, we could get rid of the Unicode reference.)
>
>thoughts?
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJhXYY055372; Thu, 27 Oct 2005 12:43:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RJhXxu055371; Thu, 27 Oct 2005 12:43:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.dave.cridland.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJhWhu055354 for <[e-mail]>; Thu, 27 Oct 2005 12:43:32 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id CBF95154009; Thu, 27 Oct 2005 19:43:25 +0000 (UTC)
Date: Thu, 27 Oct 2005 20:43:24 +0100
Subject: Re: IESG review of draft-ietf-sieve-variables-07.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>, Sam Hartman <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

Alexey,

Sorry, but I have to agree with Sam.

On Thu Oct 27 18:11:40 2005, Alexey Melnikov wrote:
> From: 	Sam Hartman <[e-mail]>
> To: 	[e-mail]
> CC: 	[e-mail]
> 
> 
> 
> The :lower and :upper and other case-folding modifiers to the set
> action do not seem to have a well defined case mapping for
> internationalization.  It is true that the ACAP i;ascii-casemap does
> define a case folding table for part of Unicode.  However I don't
> understand how that's generally true or how consulting a comparator
> will tell me which locale to use.
> 
> 
> Please provide information on how the four ACAP comparator 
> operations
> can be consulted to determine how to map case.  Alternatively, 
> provide
> another solution or extend the definition of ACAP comparator
> sufficiently to meet your needs.

I count five, but I agree with the point - comparators act as a black 
box, and the mere fact that one of the pre-existing comparators 
happens to act *as if* it alters octets in the source octet strings 
in a manner which coincidentally looks a bit like case folding 
certainly doesn't mean that all comparators define some case folding 
semantic.

Sieve breaks the model defined in ACAP in (at least) two places:

1) In the :matches match type, which defines an operation on 
comparators which does not appear in ACAP; moreover, it defines it so 
loosely, that it's impossible to detirmine what the behaviour should 
be.

2) In the :lower, :upper, etc modifiers, which require access to the 
transformed result of the comparator. Ned Freed and others have 
argued that the result of :matches, which is in variables, should be 
those parts matched by the comparator, which also breaks this model.

For what it's worth, I apologise for not having reviewed this 
document earlier.

I think a good rule of thumb is that you need to extend comparators 
themselves if the operation makes no sense with "i;ascii-numeric", 
whose internal transformation format isn't even a string, and yet is 
not defined to fail. PREFIX and SUBSTRING operations (which are 
coalesced mistakenly into a single operation in the comparator draft) 
are defined to fail with this, so logically Sieve's new operations 
probably do as well, but this needs definitions.

Using "i;ascii-numeric" to translate a string using :upper makes no 
sense - even if there were a defined mechanism for accessing the 
internals of a comparator, the result wouldn't be a string - unless 
you then define a mechanism for coercing the result back into a 
string.

Using "i;ascii-numeric" as a comparator with :matches makes no sense, 
therefore matching is inherently broken.

I really don't mind if people want to define a "Transform" or 
"Normalize" operation on comparators, that's fine with me. Matches 
would be fine too, although I'd prefer the use of special matching 
comparators, in order to gain benefit without additional protocol 
work in other places. The trouble is that nobody has.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJHnvL052011; Thu, 27 Oct 2005 12:17:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RJHntJ052010; Thu, 27 Oct 2005 12:17:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJHiiY051983 for <[e-mail]>; Thu, 27 Oct 2005 12:17:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EVDFq-0003GH-U5; Thu, 27 Oct 2005 21:17:39 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EVDFo-0006Bs-At; Thu, 27 Oct 2005 21:17:36 +0200
Subject: Re: IESG review of draft-ietf-sieve-variables-07.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Oct 2005 21:17:27 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.691, required 12, autolearn=disabled, AWL 1.12, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

> Subject: 	discuss: draft-ietf-sieve-variables
> Date: 	Wed, 26 Oct 2005 14:41:34 -0400 (EDT)
> From: 	Sam Hartman <[e-mail]>
>
> The :lower and :upper and other case-folding modifiers to the set
> action do not seem to have a well defined case mapping for
> internationalization.  It is true that the ACAP i;ascii-casemap does
> define a case folding table for part of Unicode.  However I don't
> understand how that's generally true or how consulting a comparator
> will tell me which locale to use.
> 
> Please provide information on how the four ACAP comparator operations
> can be consulted to determine how to map case.  Alternatively, provide
> another solution or extend the definition of ACAP comparator
> sufficiently to meet your needs.

this is indeed the weakest part of the variables spec, I admit the use
of a comparator with SET is little more than handwaving to appease the
i18n concious :-).  the text is even careful to avoid implying that the
comparator _has_ such a mechanism:

        The comparator specified SHOULD be consulted to establish which
        locale to use.

"consulted" isn't very normative.  it was a trick, and Sam caught me.  I
had hoped this would slide, and later we could fix up comparators
"properly" by adding two new operations (upper case and lower case).
however, such operations can hardly be called comparisons, and they're
unary, not binary, so it's probably not such a hot idea.

another option is to leave out the whole comparator thing, and just say
(as it does already) that US-ASCII MUST be supported.  after all, all
strings in Sieve are UTF-8 encoded characters from the ISO 10646
repertoire anyway, so by not saying anything about it, we make it a
quality of implementation issue.  which it would be, _anyway_.

(at the same time, we could get rid of the Unicode reference.)

thoughts?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RHCFhN037521; Thu, 27 Oct 2005 10:12:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RHCFrq037520; Thu, 27 Oct 2005 10:12:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RHCAEn037507 for <[e-mail]>; Thu, 27 Oct 2005 10:12:13 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.162] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 27 Oct 2005 18:11:53 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Oct 2005 18:11:40 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: IESG review of draft-ietf-sieve-variables-07.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

IESG has reviewed draft-ietf-sieve-variables-07.txt and had to DISCUSS 
raised against it.

Russ Housley:

  This document updates RFC 3028.  This needs to be indicated in the
  Abstract.


The discuss comment from Sam is shown below:


-------- Original Message --------
Subject: 	discuss: draft-ietf-sieve-variables
Date: 	Wed, 26 Oct 2005 14:41:34 -0400 (EDT)
From: 	Sam Hartman <[e-mail]>
To: 	[e-mail]
CC: 	[e-mail]



The :lower and :upper and other case-folding modifiers to the set
action do not seem to have a well defined case mapping for
internationalization.  It is true that the ACAP i;ascii-casemap does
define a case folding table for part of Unicode.  However I don't
understand how that's generally true or how consulting a comparator
will tell me which locale to use.


Please provide information on how the four ACAP comparator operations
can be consulted to determine how to map case.  Alternatively, provide
another solution or extend the definition of ACAP comparator
sufficiently to meet your needs.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RH13NW036490; Thu, 27 Oct 2005 10:01:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RH13mJ036489; Thu, 27 Oct 2005 10:01:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RH134R036458 for <[e-mail]>; Thu, 27 Oct 2005 10:01:03 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 27 Oct 2005 13:00:49 -0400 id 01588097.436107C1.0000671F
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: FW: "Unicode" vs "ISO 10646"
Date: Thu, 27 Oct 2005 13:01:12 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcXa6igbPSbhHqdoTLOWTxHhloP6bwALZDKQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[e-mail]>
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>

Here's something to think about that came up during today's IESG evaluation
of draft-ietf-sieve-variables.  It might be worth talking about since the
doc needs some other edits before IESG approval.

-Scott-

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Thursday, October 27, 2005 7:32 AM
To: Scott Hollenbeck
Cc: 'IESG'
Subject: Re: "Unicode" vs "ISO 10646"

Scott Hollenbeck wrote:
>>-----Original Message-----
>>From: Brian E Carpenter [mailto:[e-mail]] 
>>Sent: Tuesday, October 25, 2005 9:59 AM
>>To: IESG
>>Subject: "Unicode" vs "ISO 10646"
>>
>>While scanning drafts in Frankfurt airport, I noticed
>>that two of them (the iris and sieve drafts) refer in the
>>text to Unicode.
>>
>>My understanding is that the IETF recommendation is to
>>use the ISO 10646 coded character set, and I thought there
>>were good reasons we specified that instead of Unicode.
>>
>>What should we be looking for in RFCs?
> 
> 
> Where is that recommendation?

RFC 2277 = BCP 18

which doesn't even mention Unicode. (Also see RFC 2130).

     Brian




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9R4tnkg062684; Wed, 26 Oct 2005 21:55:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9R4tn7j062683; Wed, 26 Oct 2005 21:55:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9R4tmJQ062677 for <[e-mail]>; Wed, 26 Oct 2005 21:55:48 -0700 (PDT) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-121.messagelabs.com!1130388944!7674782!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 15714 invoked from network); 27 Oct 2005 04:55:44 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 27 Oct 2005 04:55:44 -0000
Received: from [135.70.31.19] (unknown[135.70.31.19](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20051027045544gw100lggf7e> (Authid: tony); Thu, 27 Oct 2005 04:55:44 +0000
Message-ID: <[e-mail]>
Date: Thu, 27 Oct 2005 00:55:43 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D ACTION:draft-hansen-sieve-loop-01.txt]
X-Enigmail-Version: 0.92.1.0
Content-Type: multipart/mixed; boundary="------------050306000708020305000003"
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>

This is a multi-part message in MIME format.
--------------050306000708020305000003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

fyi

--------------050306000708020305000003
Content-Type: message/rfc822;
 name="I-D ACTION:draft-hansen-sieve-loop-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-hansen-sieve-loop-01.txt"

Received: from attrh5i.attrh.att.com ([135.38.62.12])
          by maillennium.att.com (mailgw1) with ESMTP
          id <20051026204949gw100ldbrfe>; Wed, 26 Oct 2005 20:49:49 +0000
Received: from mail121.messagelabs.com (216.82.241.195) by attrh5i.attrh.att.com (7.2.052)
        id 43527A7100244862; Wed, 26 Oct 2005 16:49:49 -0400
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-121.messagelabs.com!1130359784!7438889!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [132.151.6.71]
X-SpamReason: No, hits=0.3 required=7.0 tests=MIME_BOUND_NEXTPART,
  NO_REAL_NAME
Received: (qmail 13197 invoked from network); 26 Oct 2005 20:49:44 -0000
Received: from megatron.ietf.org (HELO megatron.ietf.org) (132.151.6.71)
  by server-14.tower-121.messagelabs.com with SMTP; 26 Oct 2005 20:49:44 -0000
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUrJP-0005rh-MD; Wed, 26 Oct 2005 15:51:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHm-0005JF-B4
	for [e-mail]; Wed, 26 Oct 2005 15:50:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17832
	for <[e-mail]>; Wed, 26 Oct 2005 15:49:54 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrUw-0007WK-Ee
	for [e-mail]; Wed, 26 Oct 2005 16:03:47 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUrHf-000750-UX
	for [e-mail]; Wed, 26 Oct 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 26 Oct 2005 15:50:03 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: I-D ACTION:draft-hansen-sieve-loop-01.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

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


	Title		: Sieve Extensions: MIME Bodypart Iteration, MIME Tests, Replacement and Enclosure
	Author(s)	: C. Daboo, T. Hansen
	Filename	: draft-hansen-sieve-loop-01.txt
	Pages		: 7
	Date		: 2005-10-26
	
The current Sieve language has no looping mechanism, a way to look at
   individual MIME parts, or any way to manipulate those individual
   parts.  This document defines extensions for each of these needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hansen-sieve-loop-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-hansen-sieve-loop-01.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-hansen-sieve-loop-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-hansen-sieve-loop-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-hansen-sieve-loop-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



--------------050306000708020305000003--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9OIGTiG087380; Mon, 24 Oct 2005 11:16:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9OIGT8i087379; Mon, 24 Oct 2005 11:16:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9OIGS4F087371 for <[e-mail]>; Mon, 24 Oct 2005 11:16:28 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 24 Oct 2005 11:16:25 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1130177784; h=Date: 	 From:Subject:MIME-version:Content-type; b=TwhmIgMHMcMcKKSPbm8qQam/k mhEuDyUu9Yv8279kRy8k/mOruQE+Y8BASewj5B68i5cTneIeiimCB8xhTu1XA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 24 Oct 2005 11:16:22 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 24 Oct 2005 11:08:07 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve notification draft
In-reply-to: "Your message dated Mon, 17 Oct 2005 10:04:56 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Sat, Oct 15, 2005 at 06:07:43PM +0100, Alexey Melnikov wrote:
> > The case I had in mind is as follows: The notification URI is stored
> > elsewhere (as an LDAP attribute or an IMAP annotation) and Sieve scripts
> > uses Sieve variables extension to specify the notification method. Is it
> > desirable for an unrecognized notification method to cause runtime
> > error? I am open to suggestions.

> People who use notifications usually consider some (or all) mails very
> important.  Silently ignoring errors, in particular when variables are
> involved and the error only happens every now and then, will make them
> think notifications were sent when they were not.

I agree that error notification is important and should be done when possible.
However, I also think it is important to keep some perspective here. Many
notification services are in fact NOTORIOUSLY unreliable. Even worse, error
reporting when failures occur is in many cases impossible as a result of how
notification services are set up or even as a result of the design of the
service.

> SMS are not reliable
> and they may complain about the service.

Right, but this cuts both ways. Errors should be reported when possible in
order to prevent blame from being laid at the wrong door - if it is SMS that
failed fine, but if there's a busted sieve script the user needs to know that
in order to distinguish it from an SMS failure. OTOH, people routinelly reach
bogus conclusions about where fault lies and no amount of persuasion will
convince them they're wrong. So, while requiring error reports may help in some
cases, in many others it will make no difference.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ODOOHq059793; Mon, 24 Oct 2005 06:24:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ODOORE059792; Mon, 24 Oct 2005 06:24:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ODON4d059785 for <[e-mail]>; Mon, 24 Oct 2005 06:24:23 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9ODQA6M026715 for <[e-mail]>; Mon, 24 Oct 2005 09:26:10 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9ODOHF277276 for <[e-mail]>; Mon, 24 Oct 2005 09:24:17 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9ODOG4312866 for <[e-mail]>; Mon, 24 Oct 2005 09:24:16 -0400
Received: from saturn ([9.2.43.75]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1130160256.1225; Mon, 24 Oct 2005 09:24:16 -0400
Date: Mon, 24 Oct 2005 09:24:16 -0400
From: Barry Leiba <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========E4A529C42D65BBD9AF9A=========="
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>

--==========E4A529C42D65BBD9AF9A==========
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Don't fall off your collective chair, but, amazingly, I did get another
edit out this morning, a half hour before the deadline.  It addresses
(or specifically ignored) all the items mentioned since the WGLC.  I'll
summarise here....

First, I removed the language about stripping white space, as we
discussed -- that will be clarified in the base spec.

> I miss a section "Interaction with Other Sieve Actions".

I added one.

>    The capability string associated with extension defined in this
>    document is "relational".
>=20
> I think this does not belong to "Conventions used in this document",
> but to its own section "Capability Identifier".

I did not put it into its own section, but moved it to the end of
"Introduction".  See below about more extensive editing.

>    The VALUE match type may be used with any comparator which returns
>    sort information.
>=20
> And which comparator of the base language does that? All, I guess,
> but I miss reading that.

I agree with Alexey that this information doesn't belong there, and we
already refer to documentation about comparators.  I strongly object to
putting ANY details of specific comparators here.  That's what the
"comparators" document is for (see [Comp] in the non-normative
references).  As Kjetil points out, you will have to look it up in the
definitive reference anyway, if there's any doubt.

> Some of the examples use domain names like "example.com.invalid" --
> why not just "example.com" ?  Not that I expect to ever see a
> ".invalid" TLD but example.tld is supposed to be for examples.

Changed.

> Also, the examples should use "elsif" rather than "elseif".

Changed.

> Some of the examples refer to a test as "being" true or false, and
> others refer to the test as "returning" true or false.  I think
> "returning" is a bad word, and would prefer e.g. "evaluates to" .

I agree; changed.

> Should the "extended example" (section 5) require "fileinto" ?

Changed.

> The last "allof" in the extended example is missing a closing paren.

Changed.

> Change:
>    MUST be declared a require clause as defined in [SIEVE].
> To:
>    MUST be declared in a require clause as defined in [SIEVE].

Changed.

> =C2=A72 and elsewhere: change [ACAP] reference to i18n document.

Changed.

> Various places: 'syntax' -> 'usage'

I only saw one.  Why change this?  I left it as it is.

> =C2=A73 perhaps there ought to be an informative reference to 'C', or =
at
> least define it somewhere as 'the C programming language'.

Grumble.  I put that in as "helpful text" in a syntax comment.  No, I'm
not going to change that -- it'd be adding too many words that are
entirely irrelevant to the spec.  I suppose I could change "C" to
"Java", if we all think that it's too unclear what "C" is.

> The phrase 'number of recipients' is not strictly right as From
> addresses can be tested and that is not a 'recipient'.

Changed to "addresses".

> Exactly what are we talking about here? The number of 'addr-spec'
> elements as defined by 2822?

Good point; I've clarified (I've used "mailbox" elements, actually,
after double-checking the 2822 grammar).

> Also, I am not sure about the comment on groups.

Clarified.

> Change:
> 	comparing the total number of "to" and "cc" addresses;
> To:
> 	compares the total number of "to" and "cc" addresses;

Changed.

> Examples: all of the examples use [...] around single string-list
> items, which is not strictly necessary. I always prefer to see the
> most 'compact' syntax representation where ever possible. This is
> just a personal preference.

I understand; and I prefer the syntax that's more easily extended (to
add a second string, for instance).  :-)  No, I don't fee strongly
here, and I'm happy to change it, but I decided to leave it alone,
since it is correct as it is.

> =C2=A78: update SIEVE reference to 3028bis.

Changed.

> [My apologies for the delay in this as well.  Barry, you may scowl at
> me when we next meet.]

I owe you a scowl in Vancouver, Philip.

> The leading broilerplate is out of date.  Possibly the trailing
> broilerplate too.

Hm, possibly... but it was accepted by the I-D editor for both the -00
and -01 updates, so I'm not going to change it now.  For more extensive
editing, this ought to be converted to XML.  I'll do that between now
and when we give it to the IESG for RFC-ification, and then it'll be
easier to add or rearrange sections, and it'll pick up the then-current
boilerplate.

> I would suggest striking the second sentence of section 2 ("Any
> comparator used..."), as this document is not the source of that
> requirement and the list of exempted comparators is no longer
> accurate.

Changed.

> The last comma in section 3.1 ("...considered true[,] if any =
pair...")
> should be removed=20

Changed (I'd already caught that one).

> In section 3.2, the phrasing of what the various tests do is a bit
> odd. The first paragraph talks about counting entities, but then
> there's no further mention of "entities".

Hm, I don't think it's odd at all.  I tried just adding "as defined
below"; see if that seems clearer to you.  Does anyone else think this
is odd or confusing?

> The reference to MATCH-TYPE in the ABNF will be rejected as there's =
no
> previous definition of the MATCH-TYPE non-terminal, not even in the
> base-spec, so it can't be added to with "=3D/".  I'm not sure what =
the
> best fix for this is.

For now, lacking time, I left this alone.  If someone has a fix, please
give me text.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

--==========E4A529C42D65BBD9AF9A==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-sieve-3431bis-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-sieve-3431bis-02.txt";
 size=15963







Sieve Working Group                                         W. =
Segmuller
Internet Draft                                                  B. =
Leiba
Obsoletes: 3431 (if approved)            IBM T.J. Watson Research =
Center
Document: draft-ietf-sieve-3431bis-02.txt                    August =
2005
                                                   Expires February =
2006

                   Sieve Extension: Relational Tests


Status of this Document

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 16, 2005.


Copyright Notice

   Copyright (C) The Internet Society (2005).


Abstract

   This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.=20



W. Segmuller, B. Leiba    Expires February 2006                [Page 1]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields. =20


Meta-information on this document

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

   This document is intended to be an update to the existing
   "relational" extension to the Sieve mail filtering language,
   available from the RFC repository as
   <ftp://ftp.isi.edu/in-notes/rfc3431.txt>.

   This document and the Sieve language itself are being discussed on
   the MTA Filters mailing list at <mailto:[e-mail]>.=20
   Subscription requests can be sent to
   <mailto:[e-mail]?body=3Dsubscribe> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119. =20

   Conventions for notations are as in [SIEVE] section 1.1, including
   the use of [KEYWORDS] and "Syntax:" label for the definition of
   action and tagged arguments syntax, and the use of [ABNF]. =20


1. Introduction

   Sieve [SIEVE] is a language for filtering e-mail messages at the =
time
   of final delivery.  It is designed to be implementable on either a
   mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Messages Access Protocol (IMAP) servers, as it has no
   variables, loops, nor the ability to shell out to external programs. =


   The RELATIONAL extension provides relational operators on the



W. Segmuller, B. Leiba    Expires February 2006                [Page 2]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


   address, envelope, and header tests.  This extension also provides a
   way of counting the entities in a message header or address field. =20

   With this extension, the sieve script may now determine if a field =
is
   greater than or less than a value instead of just equivalent.  One
   use is for the x-priority field: move messages with a priority
   greater than 3 to the "work on later" folder.  Mail could also be
   sorted by the from address.  Those userids that start with 'a'-'m' =
go
   to one folder, and the rest go to another folder. =20

   The sieve script can also determine the number of fields in the
   header, or the number of addresses in a recipient field.  For
   example: are there more than 5 addresses in the to and cc fields. =20

   The capability string associated with extension defined in this
   document is "relational".


2. Comparators

   This document does not define any comparators or exempt any
   comparators from the require clause.  Any comparator used must be
   treated as defined in [SIEVE].

   The "i;ascii-numeric" comparator, as defined in [Comp], MUST be
   supported for any implementation of this extension.  The comparator
   "i;ascii-numeric" MUST support at least 32 bit unsigned integers. =20

   Larger integers MAY be supported.  Note: the "i;ascii-numeric"
   comparator does not support negative numbers. =20


3. Match Type

   This document defines two new match types.  They are the VALUE match
   type and the COUNT match type. =20

   The syntax is:

       MATCH-TYPE =3D/ COUNT / VALUE

       COUNT =3D ":count" relational-match

       VALUE =3D ":value" relational-match

       relational-match =3D DQUOTE ( "gt" / "ge" / "lt"
                                   / "le" / "eq" / "ne" ) DQUOTE
          ; "gt" means "greater than", the C operator ">".
          ; "ge" means "greater than or equal", the C operator ">=3D".
          ; "lt" means "less than", the C operator "<".
          ; "le" means "less than or equal", the C operator "<=3D".



W. Segmuller, B. Leiba    Expires February 2006                [Page 3]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


          ; "eq" means "equal to", the C operator "=3D=3D".
          ; "ne" means "not equal to", the C operator "!=3D".


3.1.  Match Type Value

   The VALUE match type does a relational comparison between strings. =20

   The VALUE match type may be used with any comparator which returns
   sort information. =20

   A value from the message is considered the left side of the =
relation.=20
   A value from the test expression, the key-list for address, =
envelope,
   and header tests, is the right side of the relation. =20

   If there are multiple values on either side or both sides, the test
   is considered true if any pair is true.


3.2.  Match Type Count

   The COUNT match type first determines the number of the specified
   entities in the message and does a relational comparison of the
   number of entities, as defined below to the values specified in the
   test expression.

   The COUNT match type SHOULD only be used with numeric comparators. =20

   The Address Test counts the number of addresses (the number of =
"mailbox"
   elements, as defined in [RFC2822]) in the specified fields.  Group =
names
   are ignored, but the contained mailboxes are counted.

   The Envelope Test counts the number of addresses in the specified
   envelope parts.  The envelope "to" will always have only one entry,
   which is the address of the user for whom the sieve script is
   running.  There is no way a sieve script can determine if the =
message
   was actually sent to someone else using this test.  The envelope
   "from" will be 0 if the MAIL FROM is empty, or 1 if MAIL FROM is not
   empty.

   The Header Test counts the total number of instances of the =
specified
   fields.  This does not count individual addresses in the "to", "cc",
   and other recipient fields. =20

   In all cases, if more than one field name is specified, the counts
   for all specified fields are added together to obtain the number for
   comparison.  Thus, specifying ["to", "cc"] in an address COUNT test,
   compares the total number of "to" and "cc" addresses; if separate
   counts are desired, they must be done in two comparisons, perhaps
   joined by "allof" or "anyof". =20



W. Segmuller, B. Leiba    Expires February 2006                [Page 4]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


4. Interaction with Other Sieve Actions

   This specification adds two match types.  The VALUE match type only
   works with comparators that return sort information.  The COUNT =
match
   type only makes sense with numeric comparators.
  =20
   There is no interaction with any other Sieve operations, nor with =
any
   known extensions.  In particular, this specification has no effect =
on
   implicit KEEP, nor on any explicit message actions.



W. Segmuller, B. Leiba    Expires February 2006                [Page 5]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


5. Example

   Using the message:=20

       received: ...
       received: ...
       subject: example
       to: [e-mail], [e-mail]
       cc: [e-mail]

   The test:=20

       address :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]

   would evaluate to true and the test=20

       anyof ( address :count "ge" :comparator "i;ascii-numeric"
                       ["to"] ["3"],
               address :count "ge" :comparator "i;ascii-numeric"
                       ["cc"] ["3"] )

   would evaluate to false. =20

   To check the number of received fields in the header, the following
   test may be used:=20

       header :count "ge" :comparator "i;ascii-numeric"
                       ["received"] ["3"]

   This would evaluate to false.  But

       header :count "ge" :comparator "i;ascii-numeric"
                       ["received", "subject"] ["3"]

   would evaluate to true. =20

   The test:=20

       header :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]

   will always evaluate to false on an RFC 2822 compliant message =
[RFC2822],



W. Segmuller, B. Leiba    Expires February 2006                [Page 6]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


   since a message can have at most one "to" field and at most one "cc"
   field.  This test counts the number of fields, not the number of
   addresses. =20


6. Extended Example

   require ["relational", "comparator-i;ascii-numeric", "fileinto"];

   if header :value "lt" :comparator "i;ascii-numeric"
             ["x-priority"] ["3"]
   {
      fileinto "Priority";
   }

   elsif address :count "gt" :comparator "i;ascii-numeric"
              ["to"] ["5"]
   {
      # everything with more than 5 recipients in the "to" field
      # is considered SPAM
      fileinto "SPAM";
   }

   elsif address :value "gt" :all :comparator "i;ascii-casemap"
              ["from"] ["M"]
   {
      fileinto "From N-Z";
   } else {
      fileinto "From A-M";
   }

   if allof ( address :count "eq" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["1"] ,
              address :all :comparator "i;ascii-casemap"
                      ["to", "cc"] ["[e-mail]"] )
   {
      fileinto "Only me";
   }


7.  IANA Considerations

   This document requests that the IANA update the entry for the
   "relational" Sieve extension to point to this document.


8. Security Considerations

   Security considerations are discussed in [SIEVE]. =20



W. Segmuller, B. Leiba    Expires February 2006                [Page 7]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005



   An implementation MUST ensure that the test for envelope "to" only
   reflects the delivery to the current user.  It MUST not be possible
   for a user to determine if this message was delivered to someone =
else
   using this test.


9. Normative References

   [SIEVE]; Guenther, P. and Showalter, T.; "Sieve: An Email Filtering=20
   Language"; draft-ietf-sieve-3028bis; July 2005.

   [Keywords]; Bradner, S.; "Key words for use in RFCs to
   IndicateRequirement Levels"; BCP 14; RFC 2119; March 1997.

   [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: =
ABNF";
   RFC 2234; November 1997. =20

   [RFC2822]; Resnick, P.; "Internet Message Format"; RFC 2822; April
   2001.


10. Non-Normative References

   [Comp]; Newman, C., Duerst, M., and Gulbrandsen, A.;=20
   "Internet Application Protocol Collation Registry";
   draft-newman-i18n-comparator; September 2005.


11. Authors' Addresses

   Wolfgang Segmuller
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532

   Phone: [phone]
   Email: [e-mail]


   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532

   Phone: [phone]
   Email: [e-mail]






W. Segmuller, B. Leiba    Expires February 2006                [Page 8]
=0C
Internet DRAFT     Sieve Extension: Relational Tests        August 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





W. Segmuller, B. Leiba    Expires February 2006                [Page 9]

--==========E4A529C42D65BBD9AF9A==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9O0DEu3084589; Sun, 23 Oct 2005 17:13:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9O0DE9D084588; Sun, 23 Oct 2005 17:13:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9O0DDUt084581 for <[e-mail]>; Sun, 23 Oct 2005 17:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1ETpxd-0003ZM-M8; Mon, 24 Oct 2005 02:13:09 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ETpxY-00022k-Ry; Mon, 24 Oct 2005 02:13:04 +0200
Subject: Re: status of 3028bis
From: Kjetil Torgrim Homme <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 24 Oct 2005 02:12:54 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.635, required 12, autolearn=disabled, AWL 1.18, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Sun, 2005-10-23 at 23:29 +0100, Dave Cridland wrote:
> On Sun Oct 23 22:02:38 2005, Ned Freed wrote:
> > Assuming:
> > 
> > (1) An octet-based comparator.
> > (2) A single ? used in isolation with no adjacent *s or ?s.
> > (3) Well formed UTF-8 as input.
> > 
> > The somewhat surprising result is that ? can only match an ASCII 
> > character. Of
> > course something like ???? can get really interesting and match 
> > anything that
> > encodes down to four octets. 
> > 
> I think you intended to say that "?" can only match a character if it 
> is within ASCII - or more generally, if it happens to encode to a 
> single octet in UTF-8. But it'll match any octet, of course, whatever 
> character it might happen to be part of the encoding for.

yes, but since the argument to :matches has implicit anchors, another
wildcard needs to follow the ?.  e.g., with "foo?", only US-ASCII can be
matched, since all UTF-8 sequences are multi-octet.

> > A construct like:
> > 
> >     require "variables";
> >     if header :matches "subject" "*" {set "subject" "${1}"}
> >     else {set "subject" ""}
> > 
> > ends up storing the subject in all caps, which likely isn't what 
> > was intended.
> 
> I think that's a matter of interpretation.
> 
> Variables says, in section 3.2, that the list variables expand to 
> what the wildcard matched.
> 
> I see nothing saying that this must be in the internal transformation 
> of the string by a comparator (if such a thing exists), nor that it 
> should be those matching portions of the original string, but my gut 
> feeling is that a comparator should be essentially a black box - that 
> is, the internal transformations of the comparator shouldn't be 
> visible to the script.

yes, the behaviour of wildcard matching is under-specified (you might
say "unspecified"), and trying to extrapolate it from the matching
algorithm is probably wrong, especially since no one will want that
behaviour.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NNxFds083730; Sun, 23 Oct 2005 16:59:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9NNxFX7083729; Sun, 23 Oct 2005 16:59:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NNxE1v083721 for <[e-mail]>; Sun, 23 Oct 2005 16:59:14 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sun, 23 Oct 2005 16:59:12 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1130111951; h=MIME-version: 	 Content-transfer-encoding:Content-type:Date:From:Subject; b=czwL2uR 	jQOHDatjXfDwM3PpJwQp4/oUt1nRrBR4XLIke5rNpWj5rZlFT987xmGzS7vREQYM9Xu qg0Ff0+g/3qA==
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 23 Oct 2005 16:59:04 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail], Michael Haardt <[e-mail]>
To: Dave Cridland <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 23 Oct 2005 15:47:53 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: status of 3028bis
In-reply-to: "Your message dated Sun, 23 Oct 2005 23:29:08 +0100" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> > > Oh my god.  Basically, this means a Sieve implementation does not
> > > know anything about its input being UTF8.
> >
> > Quite correct. IMO this is a feature, not a bug.
> >
> >
> Hmmm... I've been reading about :matches, and I'm not so sure there
> isn't a bug here.

A specification bug, perhaps.

> :matches has a problem - its specification talks about characters,
> and in particular, "?" matches 'a single character'.

> This is all very nice, but comparators don't operate on characters
> (or if they do, they get to define what a character *is*), so exactly
> what this means is vague. It really doesn't help that neither ACAP
> nor the new "collations" draft mention any kind of matching operation
> - its sole definition is in one paragraph in RFC3028 or the new draft.

Some comparators do octets, others may group those octets in some way,
including but not limited to grouping them into things we call characters.
So it's a single something, with "something" being defined by the underlying
comparator.

I don't know the best way to write this, but that's in effect what it needs to
say.

> > > You gave an example how variables extract a single octet of a
> > sequence,
> > > and you can't even control if ? matches an incomplete UTF8
> > octet-sequence
> > > or a US-ASCII character: You can not use the matched part to
> > modify or
> > > generate mails or you risk to ruin the result.
> >
> > Assuming:
> >
> > (1) An octet-based comparator.
> > (2) A single ? used in isolation with no adjacent *s or ?s.
> > (3) Well formed UTF-8 as input.
> >
> > The somewhat surprising result is that ? can only match an ASCII
> > character. Of
> > course something like ???? can get really interesting and match
> > anything that
> > encodes down to four octets.
> >
> I think you intended to say that "?" can only match a character if it
> is within ASCII - or more generally, if it happens to encode to a
> single octet in UTF-8. But it'll match any octet, of course, whatever
> character it might happen to be part of the encoding for.

Yes, but this fails to take the context into account. There are three subcases
where ? appears at the beginning, middle, or end of the pattern.

If ? appears at the beginning and the target begins with a non-ASCII character,
the ? will match the first octet of that character. But since this is well
formed UTF-8 there has to be a second byte and that byte cannot possibly
match the next thing in the pattern. So the the match always fails unless
the first character of the target is ASCII.

I won't bother to walk through the remaining cases, but they all end up the
same way: The ? may match a non-ASCII character in isolation, but unless it is
adjacent to some other wildcard there is no way the entire pattern can
subsequently match.

> > Well, we have quite a large user based on this stuff and most of
> > these issues have proved to be theoretical. Variables may change this,
> > however.
> > A construct like:
> >
> >     require "variables";
> >     if header :matches "subject" "*" {set "subject" "${1}"}
> >     else {set "subject" ""}
> >
> > ends up storing the subject in all caps, which likely isn't what
> > was intended.

> I think that's a matter of interpretation.

> Variables says, in section 3.2, that the list variables expand to
> what the wildcard matched.

But what the wildcard matched was transformed text. Try as I might, I cannot
read what's there the way you do.

> I see nothing saying that this must be in the internal transformation
> of the string by a comparator (if such a thing exists), nor that it
> should be those matching portions of the original string, but my gut
> feeling is that a comparator should be essentially a black box - that
> is, the internal transformations of the comparator shouldn't be
> visible to the script.

Although it will be some work for me to change my implementation to match
this, I would be happy to make such a change because I think the resulting
behavior is better. However, if this is what people want it needs to be
made explicit in the variables specification. I think your reading of
what's there now is a huge stretch.

> This is especially true since some comparators don't transform to a
> string internally - not that we should be trying matches with
> "i;ascii-numeric" (and why is this remaining "i;" if we have to
> change "i;ascii-casemap"? ASCII digits aren't available everywhere.
> Perhaps I'm being naïve again.)

IMO we have much too much deployed code to change the names of any of these
things. At the very most we can add new names and make the new names the
preferred names. The old names have to remain and be recognized indefinitely.

> Moreover:

> require "variables";
> if header "subject" :comparator "i;ascii-casemap" :matches "[foo] *" {
> 	set "subject" "${1}";
> } else {
> 	set "subject" "${1}";
> }

> would be a whole load more useful if ${subject} was a substring of
> the original subject, rather than an upper-case variant of it.

Yes, that's the case that argues strongly for your approach. It is also worth
nothing that those who want to force things into a particular case can do so
with the various modifiers to set.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NMTH04075864; Sun, 23 Oct 2005 15:29:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9NMTHgE075863; Sun, 23 Oct 2005 15:29:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.dave.cridland.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NMTFVm075851 for <[e-mail]>; Sun, 23 Oct 2005 15:29:16 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id B403E154009; Sun, 23 Oct 2005 22:29:09 +0000 (UTC)
Date: Sun, 23 Oct 2005 23:29:08 +0100
Subject: Re: status of 3028bis
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: <[e-mail]>, Michael Haardt <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
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>

On Sun Oct 23 22:02:38 2005, Ned Freed wrote:
> 
> 
> > On Fri, Oct 21, 2005 at 02:38:29AM +0200, Kjetil Torgrim Homme 
> wrote:
> > >    The "en;ascii-casemap" collation is a simple collation 
> intended for
> > >    use with English language text in pure US-ASCII.  It provides
> > >    equality, substring and ordering functions.  The algorithm 
> first
> > >    applies a canonicalization algorithm to both input strings 
> which
> > >    subtracts 32 (0x20) from all octet values between 97 (0x61) 
> and 122
> > >    (0x7A) inclusive.  The result of the collation is then the 
> same as
> > >    the result of the "i;octet" collation for the canonicalized 
> strings.
> > >
> > > (the algorithm in RFC 2244 is essentially the same.)
> > >
> > > this was surprising and interesting to me, since it means that 
> with
> > > "abc" :matches "ab?", ${1} will hold the uppercase "C"!  I 
> wonder how
> > > many users would expect that one, or how many implementations 
> get it
> > > right.
> 
> > Oh my god.  Basically, this means a Sieve implementation does not
> > know anything about its input being UTF8.
> 
> Quite correct. IMO this is a feature, not a bug.
> 
> 
Hmmm... I've been reading about :matches, and I'm not so sure there 
isn't a bug here.

:matches has a problem - its specification talks about characters, 
and in particular, "?" matches 'a single character'.

This is all very nice, but comparators don't operate on characters 
(or if they do, they get to define what a character *is*), so exactly 
what this means is vague. It really doesn't help that neither ACAP 
nor the new "collations" draft mention any kind of matching operation 
- its sole definition is in one paragraph in RFC3028 or the new draft.

> > You gave an example how variables extract a single octet of a 
> sequence,
> > and you can't even control if ? matches an incomplete UTF8 
> octet-sequence
> > or a US-ASCII character: You can not use the matched part to 
> modify or
> > generate mails or you risk to ruin the result.
> 
> Assuming:
> 
> (1) An octet-based comparator.
> (2) A single ? used in isolation with no adjacent *s or ?s.
> (3) Well formed UTF-8 as input.
> 
> The somewhat surprising result is that ? can only match an ASCII 
> character. Of
> course something like ???? can get really interesting and match 
> anything that
> encodes down to four octets. 
> 
I think you intended to say that "?" can only match a character if it 
is within ASCII - or more generally, if it happens to encode to a 
single octet in UTF-8. But it'll match any octet, of course, whatever 
character it might happen to be part of the encoding for.


> > > this is truly a mess.  we need a comparator which makes sense, a
> > > comparator which operates case-fully on Unicode characters, but 
> without
> > > the difficult bits (e.g. normalising combining characters).
> 
> 
I'm certainly in full agreement there.


> Well, we have quite a large user based on this stuff and most of 
> these
> issues have proved to be theoretical. Variables may change this, 
> however.
> A construct like:
> 
>     require "variables";
>     if header :matches "subject" "*" {set "subject" "${1}"}
>     else {set "subject" ""}
> 
> ends up storing the subject in all caps, which likely isn't what 
> was intended.

I think that's a matter of interpretation.

Variables says, in section 3.2, that the list variables expand to 
what the wildcard matched.

I see nothing saying that this must be in the internal transformation 
of the string by a comparator (if such a thing exists), nor that it 
should be those matching portions of the original string, but my gut 
feeling is that a comparator should be essentially a black box - that 
is, the internal transformations of the comparator shouldn't be 
visible to the script.

This is especially true since some comparators don't transform to a 
string internally - not that we should be trying matches with 
"i;ascii-numeric" (and why is this remaining "i;" if we have to 
change "i;ascii-casemap"? ASCII digits aren't available everywhere. 
Perhaps I'm being naïve again.)

Moreover:

require "variables";
if header "subject" :comparator "i;ascii-casemap" :matches "[foo] *" {
	set "subject" "${1}";
} else {
	set "subject" "${1}";
}

would be a whole load more useful if ${subject} was a substring of 
the original subject, rather than an upper-case variant of it.

> I believe that some of the examples in the variables draft make 
> have similar
> mistakes in them.

Different interpretations, rather than mistakes.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NLKRTw071154; Sun, 23 Oct 2005 14:20:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9NLKRXH071153; Sun, 23 Oct 2005 14:20:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9NLKQ98071147 for <[e-mail]>; Sun, 23 Oct 2005 14:20:26 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sun, 23 Oct 2005 14:20:23 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1130102423; h=Date: 	 From:Subject:MIME-version:Content-type; b=Vtj5T2NhiV38vgcpCna+29Pal HsgP/7XZnpUoQPwcimsQVTsehL6jooetCLfRh4IFbOszxYxaSEwnN9Tr7G1bQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 23 Oct 2005 14:20:20 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 23 Oct 2005 14:02:38 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: status of 3028bis
In-reply-to: "Your message dated Fri, 21 Oct 2005 12:29:13 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Fri, Oct 21, 2005 at 02:38:29AM +0200, Kjetil Torgrim Homme wrote:
> >    The "en;ascii-casemap" collation is a simple collation intended for
> >    use with English language text in pure US-ASCII.  It provides
> >    equality, substring and ordering functions.  The algorithm first
> >    applies a canonicalization algorithm to both input strings which
> >    subtracts 32 (0x20) from all octet values between 97 (0x61) and 122
> >    (0x7A) inclusive.  The result of the collation is then the same as
> >    the result of the "i;octet" collation for the canonicalized strings.
> >
> > (the algorithm in RFC 2244 is essentially the same.)
> >
> > this was surprising and interesting to me, since it means that with
> > "abc" :matches "ab?", ${1} will hold the uppercase "C"!  I wonder how
> > many users would expect that one, or how many implementations get it
> > right.

> Oh my god.  Basically, this means a Sieve implementation does not
> know anything about its input being UTF8.

Quite correct. IMO this is a feature, not a bug.

> All it does is converting
> headers to UTF8, but other than that, it works on octets, not characters.

Well, it has always been possible to specify a comparator that operates
on characters rather than octets. I've had the hooks in place for this
in our implementation waiting for the comparator stuff to be completed.

> If so, we must not talk about unicode, but UTF8, and s/character/octet/g.
> And I have to change my implementation, which works on characters,
> crippling it.

There are advantages as well as drawbacks. The ability to match illegal gunk is
something I've used more than once, and I know that some of our cusstomers have
used it too.

> Do all implementations else work on octets instead of characters?

Ours does.

> > > Are you saying that even using "en;ascii-casemap", the wildcard "?"
> > > does not match a single character outside US-ASCII?
> >
> > since the spec defines it in terms of i;octet, the "?" wildcard is
> > essentially broken.  it gets really interesting with "*", though, since
> > you will probably get doubly encoded UTF-8 :-(

> Worse, matched octets can be invalid (incomplete) UTF8 octet-sequences.

The underlying structure of UTF-8 itself tends to minimize the liklihood of
this happening. As long as you're dealing with well formed UTF-8 inputs there
is no way for part of one character to match part of another. (This is one of
the real advantages of UTF-8 over, say, UTF-16 - you can perform byte by byte
comparisons and most things end up working properly. :matches and ? are an
obvious exception, of course.)

Of course once you leave the realm of well formed utf-8 this no longer
applies.

> You gave an example how variables extract a single octet of a sequence,
> and you can't even control if ? matches an incomplete UTF8 octet-sequence
> or a US-ASCII character: You can not use the matched part to modify or
> generate mails or you risk to ruin the result.

Assuming:

(1) An octet-based comparator.
(2) A single ? used in isolation with no adjacent *s or ?s.
(3) Well formed UTF-8 as input.

The somewhat surprising result is that ? can only match an ASCII character. Of
course something like ???? can get really interesting and match anything that
encodes down to four octets. 

> > this is truly a mess.  we need a comparator which makes sense, a
> > comparator which operates case-fully on Unicode characters, but without
> > the difficult bits (e.g. normalising combining characters).

Well, we have quite a large user based on this stuff and most of these
issues have proved to be theoretical. Variables may change this, however.
A construct like:

    require "variables";
    if header :matches "subject" "*" {set "subject" "${1}"}
    else {set "subject" ""}

ends up storing the subject in all caps, which likely isn't what was intended.
For this to work properly you need to say:

    require "variables";
    if header :comparator "i;octet" :matches "subject" "*" {set "subject" "${1}"}
    else {set "subject" ""}

I believe that some of the examples in the variables draft make have similar
mistakes in them.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9MM8s8g056807; Sat, 22 Oct 2005 15:08:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9MM8snN056806; Sat, 22 Oct 2005 15:08:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9MM8s90056792 for <[e-mail]>; Sat, 22 Oct 2005 15:08:54 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sat, 22 Oct 2005 15:08:50 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1130018929; h=Date: 	 From:Subject:MIME-version:Content-type; b=zRu0iLZpPxgmx+jg+4dF0FJ4Y e/7fk1BCi3H+6rED9SCZr9FMyHpVCyVXdKdkY2Oqf3uufT2MhFmojExwEGxfA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 22 Oct 2005 15:08:45 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 22 Oct 2005 15:08:00 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Fri, 21 Oct 2005 19:20:42 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Fri, Oct 21, 2005 at 03:15:32PM -0700, Ned Freed wrote:
> > > Hmm, going back again... perhaps you were reading my "non-first
> > > vacation" as "non-vacation" ?
> >
> > Yes.

> OK.  That explains the disconnect, and renders a lot of this
> mini-thread irrelevant.

> If you thought I was suggesting that the first non-vacation action
> after multiple vacation actions should cause an error, well, you
> were very generous in your responses :-)

OK, got it. I'm really glad to hear this isn't what you were proposing.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9MBfhoU006446; Sat, 22 Oct 2005 04:41:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9MBfhXl006445; Sat, 22 Oct 2005 04:41:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.dave.cridland.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9MBff6p006411 for <[e-mail]>; Sat, 22 Oct 2005 04:41:41 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 14BCA154009; Sat, 22 Oct 2005 11:41:35 +0000 (UTC)
Date: Sat, 22 Oct 2005 12:41:33 +0100
Subject: Re: status of 3028bis
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

On Fri Oct 21 11:29:13 2005, Michael Haardt wrote:
> 
> On Fri, Oct 21, 2005 at 02:38:29AM +0200, Kjetil Torgrim Homme 
> wrote:
> >    The "en;ascii-casemap" collation is a simple collation 
> intended for
> >    use with English language text in pure US-ASCII.  It provides
> >    equality, substring and ordering functions.  The algorithm 
> first
> >    applies a canonicalization algorithm to both input strings 
> which
> >    subtracts 32 (0x20) from all octet values between 97 (0x61) 
> and 122
> >    (0x7A) inclusive.  The result of the collation is then the 
> same as
> >    the result of the "i;octet" collation for the canonicalized 
> strings.
> > > (the algorithm in RFC 2244 is essentially the same.)
> > > this was surprising and interesting to me, since it means that 
> with
> > "abc" :matches "ab?", ${1} will hold the uppercase "C"!  I wonder 
> how
> > many users would expect that one, or how many implementations get 
> it
> > right.
> 
> Oh my god.  Basically, this means a Sieve implementation does not
> know anything about its input being UTF8.  All it does is converting
> headers to UTF8, but other than that, it works on octets, not 
> characters.
> 
> 
Yep. But don't be too alarmed, this only breaks :matches.

Incidentally, I really suspect that :matches in this case should be 
returning "c", not "C", and it depends heavily on a lot of 
specification that I suspect doesn't exist.


> If so, we must not talk about unicode, but UTF8, and 
> s/character/octet/g.
> And I have to change my implementation, which works on characters,
> crippling it.
> 
> Do all implementations else work on octets instead of characters?
> 
> 
It actually doesn't matter. All the comparators so far defined at RFC 
level (ie, by ACAP), operate on octets, not characters, but assuming 
your implementation (modulo :matches) operates such that *if* all 
comapators operated on UTF-8 encoded octet strings rather than 
Unicode character strings, then this is easily rectifiable.

:matches is the problem.


> > > Are you saying that even using "en;ascii-casemap", the wildcard 
> "?"
> > > does not match a single character outside US-ASCII?
> > > since the spec defines it in terms of i;octet, the "?" wildcard 
> is
> > essentially broken.  it gets really interesting with "*", though, 
> since
> > you will probably get doubly encoded UTF-8 :-(
> 
> Worse, matched octets can be invalid (incomplete) UTF8 
> octet-sequences.
> You gave an example how variables extract a single octet of a 
> sequence,
> and you can't even control if ? matches an incomplete UTF8 
> octet-sequence
> or a US-ASCII character: You can not use the matched part to modify 
> or
> generate mails or you risk to ruin the result.
> 
> 
Yes, true. Fun, isn't it?


> > this is truly a mess.  we need a comparator which makes sense, a
> > comparator which operates case-fully on Unicode characters, but 
> without
> > the difficult bits (e.g. normalising combining characters).
> 
> Indeed!
> 
> 
This is a very, very quick proposal that I've had in the back of my 
mind, but the use of :matches convinces me that this is the way to go.

The current comparator draft changed the name of comparators to 
collations - I thought that was wrong, because I'd have liked to see 
comparators that performed pattern matching, which precludes their 
ability to collate.

I'd like to propose:

1) A family of comparators for both UTF-8 and Octet matching, the 
matches themselves being Globs (as Sieve :matches), and regular 
expressions. (perhaps Basic and Extended). This is off the top of my 
head, and it's a Saturday, so I can't recall the conventions for 
comparator naming, but I'll use the example of "i;utf-8;glob".

This comparator would perform the "EQUAL" operation such that if the 
left hand side were matched by the pattern contained in the 
right-hand side, it returned true, otherwise false.

"SUBSTRING" would match if the pattern occured anywhere in the 
string, and "PREFIX" if it occured at the beginning of the string.

We need at least a UTF-8 glob to replace :matches, and a case-folding 
variant, too.

2) A new API requirement that "submatches" may be extracted from the 
result of a successful EQUAL, PREFIX, or SUBSTRING match.

3) In Sieve, :matches becomes deprecated, and for backwards 
compatibility, it should be rewritten such that:

a) The comparator is changed from "i;octet" to "i;utf-8;glob", and 
from "i;ascii-casemap" to "en;utf-8;casemap;glob".

b) The operation is changed from :matches to :is

The net result is not only that :matches now works as people expect, 
but that regular expression searching and glob pattern matching 
become available in ACAP and IMAP, too.

So I can do something like EQUAL "addressbook.Email" 
"en;utf-8;casemap;regex" "dave(\\+[^@]*)?@cridland.net(\0[a-z]*)?" 
when searching my addressbook, which'd keep me happy.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LNKi4G018972; Fri, 21 Oct 2005 16:20:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LNKiva018971; Fri, 21 Oct 2005 16:20:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9LNKh7B018957 for <[e-mail]>; Fri, 21 Oct 2005 16:20:43 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 42370 invoked by uid 101); 21 Oct 2005 19:20:42 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 21 Oct 2005 19:20:42 -0400
To: Ned Freed <[e-mail]>
Cc: Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Fri, Oct 21, 2005 at 03:15:32PM -0700, Ned Freed wrote:
> > Hmm, going back again... perhaps you were reading my "non-first
> > vacation" as "non-vacation" ?
> 
> Yes.

OK.  That explains the disconnect, and renders a lot of this
mini-thread irrelevant.

If you thought I was suggesting that the first non-vacation action
after multiple vacation actions should cause an error, well, you
were very generous in your responses :-)


> > There is certainly precedent for suppressing duplicate vacation
> > actions.
> 
> I disagree. AFAIK we have no other situation where repeating an action is
> supposed to be an error but repeating an identical action doesn't produce an
> error. The obvious case where repeating an action is an error is reject, and
> it's an error even if the second reject is identical.
> 
> > The base spec says (at least the way I read it, and thus the
> > way I implemented it) that multiple attempts to file into a folder will
> > be silently suppressed.
> 
> The cases are not really comparable. Multiple fileintos are not an automatic
> error. The only time multiple fileintos would produce an error is when they
> exceed the implementation's limit on fileintos, and the spec is silent (as it
> should be) on whether or not such a limit counts identical fileinto separately
> or not.

I understand that difference, and your perspective on it.  Me, I
find de-duplication of identical vacations (and even rejects) to
offer the most consistency and utility.  But I'll implement whatever
the RFC ends up saying in this regard.



> > I completely agree with that.  What I don't understand is how it applies
> > to this particular point.  (OTOH, unrelated to vacation, it could apply
> > in an implementation that defers actions.)
> 
> See above. I don't know what else I can say.

It was explained by the fundamental miscommunication anyway.

Yours,
-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LMoGL0011645; Fri, 21 Oct 2005 15:50:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LMoGqW011644; Fri, 21 Oct 2005 15:50:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LMoFes011637 for <[e-mail]>; Fri, 21 Oct 2005 15:50:16 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 21 Oct 2005 15:50:14 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129935013; h=Date: 	 From:Subject:MIME-version:Content-type; b=w4Yu4rEEryt35HgIWxbufEkbY M48F6ipWc5TxW/58NVg4qGSY+4H7WOE+LGO70o0Wf0Qq4uKV8rUC5vVJONVrA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Oct 2005 15:50:10 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 21 Oct 2005 15:15:32 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Fri, 21 Oct 2005 16:42:03 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Fri, Oct 21, 2005 at 01:07:53PM -0700, Ned Freed wrote:
> > > On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
> > > > > On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > > > >     I did wonder about that wording; seems to me that the the script as
> > > > >     a whole probably shouldn't fail, but the non-first vacation
> > > > >     action(s) should give an error.  i.e. duplication vacation actions
> > > > >     should fail, not abort the entire script.  (Not to mention that if
> > > > >     the script were to fail on the second "vacation" then there would be
> > > > >     no need to say "or more".)
> > > >
> > > > I think this is an absolutely terrible idea.
> >
> > > Which idea do you think is terrible?  Multiple vacations causing a script
> > > to fail, or simply reporting an error on a multiple vacation?
> >
> > The idea that multiple vacation action errors should be silently ignored
> > until the first non-vacation action is taken.

> Ah.  But that's a third case.  Why would the first non-vacation action
> cause an error?  The context was whether in:

>    vacation :handle x "something";   # A
>    vacation :handle x "something";   # B

> whether executing B causes the script to fail, or whether the script
> continues past B (suppressing the execution of the B action, whether
> noting an error or not).

It should cause the script to fail.

> A later non-vacation action (in this case,
> "fileinto") shouldn't cause an error whether there is one vacation
> statement or two.  So the example is still confusing to me.
> Particularly the comment about the success of the test mattering, rather
> than the multiple vacation actions being executed.

> Hmm, going back again... perhaps you were reading my "non-first
> vacation" as "non-vacation" ?

Yes.

> There is certainly precedent for suppressing duplicate vacation
> actions.

I disagree. AFAIK we have no other situation where repeating an action is
supposed to be an error but repeating an identical action doesn't produce an
error. The obvious case where repeating an action is an error is reject, and
it's an error even if the second reject is identical.

> The base spec says (at least the way I read it, and thus the
> way I implemented it) that multiple attempts to file into a folder will
> be silently suppressed.

The cases are not really comparable. Multiple fileintos are not an automatic
error. The only time multiple fileintos would produce an error is when they
exceed the implementation's limit on fileintos, and the spec is silent (as it
should be) on whether or not such a limit counts identical fileinto separately
or not.

> > > > VIolations of the least
> > > > astonishment principle abound. Consider:
> > > >
> > > >     vacation whatever1;
> > > >     vacation whatever2;
> > > >     if test {fileinto blah;}
> > > >
> > > > If the test fails the script appears to work, sending one vacation response
> > > > but not the other. But if the test succeeds the script now fails for reasons
> > > > having nothing to do with the test. Such a gotcha can remain hidden
> > > > indefinitely only to go off when you least expect it - a script landmine.

> I still don't get that.  Probably it's me.  When you invoke the
> principle of least astonishment, I find that that is accomplished by
> making the vacation action work in the same way as fileinto, for the
> same reason.

Perhaps, but this consideration is trumped by the fact that sending multiple
vacation messages is a bad thing thing. Multiple fileintos, OTOH, make total
sense in a lot of cases.

> And with duplicate vacation causing a failure, you get
> that 'landmine' (which I would simply describe as a coding error) even
> more with:

>    vacation whatever1;
>    if test { vacation whatever2; }
>    fileinto "blah";

Some issues can be avoided, others cannot. Deferring errors is something we can
avoid specifying. Unless we're willing to make all actions unconditionally
compatible with all others we cannot possibly get rid of all these cases.
Making something like:

    reject "foo"
    if test { fileinto "bar";}

work regardless of how the test turns out isn't worth eliminating the
restriction that reject isn't compatible with most other actions.

> > The minute you have failure cases that don't report when encountered and
> > instead wait for some other condition to arise before becoming an error you've
> > got a mess on your hands.

> I completely agree with that.  What I don't understand is how it applies
> to this particular point.  (OTOH, unrelated to vacation, it could apply
> in an implementation that defers actions.)

See above. I don't know what else I can say.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LKg5lU084413; Fri, 21 Oct 2005 13:42:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LKg543084412; Fri, 21 Oct 2005 13:42:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9LKg49I084403 for <[e-mail]>; Fri, 21 Oct 2005 13:42:04 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 40868 invoked by uid 101); 21 Oct 2005 16:42:03 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 21 Oct 2005 16:42:03 -0400
To: Ned Freed <[e-mail]>
Cc: Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Fri, Oct 21, 2005 at 01:07:53PM -0700, Ned Freed wrote:
> > On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
> > > > On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > > >     I did wonder about that wording; seems to me that the the script as
> > > >     a whole probably shouldn't fail, but the non-first vacation
> > > >     action(s) should give an error.  i.e. duplication vacation actions
> > > >     should fail, not abort the entire script.  (Not to mention that if
> > > >     the script were to fail on the second "vacation" then there would be
> > > >     no need to say "or more".)
> > >
> > > I think this is an absolutely terrible idea.
> 
> > Which idea do you think is terrible?  Multiple vacations causing a script
> > to fail, or simply reporting an error on a multiple vacation?
> 
> The idea that multiple vacation action errors should be silently ignored
> until the first non-vacation action is taken.

Ah.  But that's a third case.  Why would the first non-vacation action
cause an error?  The context was whether in:

   vacation :handle x "something";   # A
   vacation :handle x "something";   # B

whether executing B causes the script to fail, or whether the script
continues past B (suppressing the execution of the B action, whether
noting an error or not).  A later non-vacation action (in this case,
"fileinto") shouldn't cause an error whether there is one vacation
statement or two.  So the example is still confusing to me.
Particularly the comment about the success of the test mattering, rather
than the multiple vacation actions being executed.

Hmm, going back again... perhaps you were reading my "non-first
vacation" as "non-vacation" ?

There is certainly precedent for suppressing duplicate vacation
actions.  The base spec says (at least the way I read it, and thus the
way I implemented it) that multiple attempts to file into a folder will
be silently suppressed.  See 2.10.3, which says:

   > Implementations SHOULD NOT deliver a message to the same folder more
   > than once, even if a script explicitly asks for a message to be
   > written to a mailbox twice.
   > 
   > The test for equality of two messages is implementation-defined.
   > 
   > If a script asks for a message to be written to a mailbox twice, it
   > MUST NOT be treated as an error.

I don't know the reasoning behind this, but I assumed it is to make it
convenient and harmless for a script writer to express their intent to
write a message into a particular folder when more than one test
succeeds.  ("I twice intend to write into this folder" rather than "I
intend to write into this folder twice").

> 
> > > VIolations of the least
> > > astonishment principle abound. Consider:
> > >
> > >     vacation whatever1;
> > >     vacation whatever2;
> > >     if test {fileinto blah;}
> > >
> > > If the test fails the script appears to work, sending one vacation response
> > > but not the other. But if the test succeeds the script now fails for reasons
> > > having nothing to do with the test. Such a gotcha can remain hidden
> > > indefinitely only to go off when you least expect it - a script landmine.

I still don't get that.  Probably it's me.  When you invoke the
principle of least astonishment, I find that that is accomplished by
making the vacation action work in the same way as fileinto, for the
same reason.  And with duplicate vacation causing a failure, you get
that 'landmine' (which I would simply describe as a coding error) even
more with:

   vacation whatever1;
   if test { vacation whatever2; }
   fileinto "blah";

since when the test fails, you get one vacation response and the message
filed into blah; if the test succeeds, you get a vacation response and
you do not get the message filed into blah (rather, the inbox).  This
seems more along the lines of your view of a landmine; how is this
better?


> The minute you have failure cases that don't report when encountered and
> instead wait for some other condition to arise before becoming an error you've
> got a mess on your hands.

I completely agree with that.  What I don't understand is how it applies
to this particular point.  (OTOH, unrelated to vacation, it could apply
in an implementation that defers actions.)

Yours,
-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LKAa4x077199; Fri, 21 Oct 2005 13:10:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LKAaRZ077198; Fri, 21 Oct 2005 13:10:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LKAZdf077188 for <[e-mail]>; Fri, 21 Oct 2005 13:10:35 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 21 Oct 2005 13:10:30 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129925429; h=Date: 	 From:Subject:MIME-version:Content-type; b=TfBdVtAQND5UOYskh/mRMs1Q4 eyoJyiCGka0IXE1atziYfrHfBVArw2v8xt+hDVjEbuRIFsJnHY+/SvnSi0w6Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Oct 2005 13:10:28 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 21 Oct 2005 13:07:53 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Fri, 21 Oct 2005 15:30:25 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
> > > On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > > >
> > > > Section 4.7: "A script will fail if it attempts to execute two or more
> > > > vacation actions."
> > > > Should "will" be either SHOULD or MUST?  "will" describes an implementation
> > > > behavior.
> >
> > > I also had a comment on 4.7 that I sent off-list.  Essentially:
> >
> > >     I did wonder about that wording; seems to me that the the script as
> > >     a whole probably shouldn't fail, but the non-first vacation
> > >     action(s) should give an error.  i.e. duplication vacation actions
> > >     should fail, not abort the entire script.  (Not to mention that if
> > >     the script were to fail on the second "vacation" then there would be
> > >     no need to say "or more".)
> >
> > I think this is an absolutely terrible idea.

> Which idea do you think is terrible?  Multiple vacations causing a script
> to fail, or simply reporting an error on a multiple vacation?

The idea that multiple vacation action errors should be silently ignored
until the first non-vacation action is taken.

> > VIolations of the least
> > astonishment principle abound. Consider:
> >
> >     vacation whatever1;
> >     vacation whatever2;
> >     if test {fileinto blah;}
> >
> > If the test fails the script appears to work, sending one vacation response
> > but not the other. But if the test succeeds the script now fails for reasons
> > having nothing to do with the test. Such a gotcha can remain hidden
> > indefinitely only to go off when you least expect it - a script landmine.

> I do not understand this example at all; perhaps some more words would
> help light the bulb.  (or perhaps hitting "send" on this message will do
> it :-) ).  If anything, it sounds like you do not want the script to
> fail if there are multiple vacation statements.

No. That's exactly the opposite of what I want.

> But I don't understand
> how the success or failure of the test causes any more of a debugging
> problem with any particular duplicate-vacation handling vs another.

The minute you have failure cases that don't report when encountered and
instead wait for some other condition to arise before becoming an error you've
got a mess on your hands.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LJk7vP072032; Fri, 21 Oct 2005 12:46:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LJk7Qb072031; Fri, 21 Oct 2005 12:46:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LJk6bo072023 for <[e-mail]>; Fri, 21 Oct 2005 12:46:06 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ET2q6-0008K2-CJ; Fri, 21 Oct 2005 15:46:06 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Sieve Email Filtering: Vacation Extension' to Proposed  Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 21 Oct 2005 15:46:06 -0400
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>

The IESG has received a request from the Sieve Mail Filtering Language WG to 
consider the following document:

- 'Sieve Email Filtering: Vacation Extension '
   <draft-ietf-sieve-vacation-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2005-11-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-04.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LJURIT067874; Fri, 21 Oct 2005 12:30:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LJURGG067872; Fri, 21 Oct 2005 12:30:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9LJUPxG067865 for <[e-mail]>; Fri, 21 Oct 2005 12:30:26 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 97442 invoked by uid 101); 21 Oct 2005 15:30:25 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 21 Oct 2005 15:30:25 -0400
To: Ned Freed <[e-mail]>
Cc: Mark E Mallett <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
> > On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > >
> > > Section 4.7: "A script will fail if it attempts to execute two or more
> > > vacation actions."
> > > Should "will" be either SHOULD or MUST?  "will" describes an implementation
> > > behavior.
> 
> > I also had a comment on 4.7 that I sent off-list.  Essentially:
> 
> >     I did wonder about that wording; seems to me that the the script as
> >     a whole probably shouldn't fail, but the non-first vacation
> >     action(s) should give an error.  i.e. duplication vacation actions
> >     should fail, not abort the entire script.  (Not to mention that if
> >     the script were to fail on the second "vacation" then there would be
> >     no need to say "or more".)
> 
> I think this is an absolutely terrible idea.

Which idea do you think is terrible?  Multiple vacations causing a script
to fail, or simply reporting an error on a multiple vacation?


> VIolations of the least
> astonishment principle abound. Consider:
> 
>     vacation whatever1;
>     vacation whatever2;
>     if test {fileinto blah;}
> 
> If the test fails the script appears to work, sending one vacation response
> but not the other. But if the test succeeds the script now fails for reasons
> having nothing to do with the test. Such a gotcha can remain hidden
> indefinitely only to go off when you least expect it - a script landmine.

I do not understand this example at all; perhaps some more words would
help light the bulb.  (or perhaps hitting "send" on this message will do
it :-) ).  If anything, it sounds like you do not want the script to
fail if there are multiple vacation statements.  But I don't understand
how the success or failure of the test causes any more of a debugging
problem with any particular duplicate-vacation handling vs another.

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LI5gxT050903; Fri, 21 Oct 2005 11:05:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LI5ggh050902; Fri, 21 Oct 2005 11:05:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LI5gc0050896 for <[e-mail]>; Fri, 21 Oct 2005 11:05:42 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 21 Oct 2005 11:05:40 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129917940; h=Date: 	 From:Subject:MIME-version:Content-type; b=aDNo1jsYP7FJ1/2s1FkF8gl/r toaa0Jyv+DlCyklo/Z/eja/tqTQPoJDUUjBYkUxOT61xI2fKXN3Fn/QcJMEbQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Oct 2005 11:05:37 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 21 Oct 2005 10:52:17 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Fri, 21 Oct 2005 01:22:08 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Thu, Oct 20, 2005 at 03:58:35PM -0400, Mark E. Mallett wrote:
> >
> > On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > >
> > > Section 4.7: "A script will fail if it attempts to execute two or more
> > > vacation actions."
> > > Should "will" be either SHOULD or MUST?  "will" describes an implementation
> > > behavior.
> >
> > I also had a comment on 4.7 that I sent off-list.  Essentially:
> >
> >     I did wonder about that wording; seems to me that the the script as
> >     a whole probably shouldn't fail, but the non-first vacation
> >     action(s) should give an error.  i.e. duplication vacation actions
> >     should fail, not abort the entire script.  (Not to mention that if
> >     the script were to fail on the second "vacation" then there would be
> >     no need to say "or more".)

> The base spec says:

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

> So either you ignore vacation actions starting at the second one, or
> you generate an error.  If an error is generated, all processing stops.
> If so, indeed there can't be a third.

> I'd say, let's include an example showing two vacation actions and
> a fileinto afterwards, stating the fileinto can not happen (assuming
> the second vacation action does generate an error), but:

I see no reason to have such an example.

> Does the base spec allow action execution reordering?

There's no prohibition against it, so the answer would apppear to be "yes". The
base spec does go so far as to say that you can perform actions as you go or
wait until evaluation is complete and then perform them all.

> That's not as crazy as it sounds.

IMO it doesn't sound crazy at all.

> Of course actions with side effects
> must not be reordered, that goes without saying.  And how about actions
> without side effects?

> fileinto "a";
> fileinto "b";

> If a message is filed to "b", will there be one in "a", or could
> both actions be processed simultaneous after the script ran, "a"
> fails with a runtime error and "b" suceeds?

Sure, that's possible. Or you could have a situation where "a" is over quota
but "b" is not. And what about transient quota errors? Suppose "a" is over
quota but still within it's "grace period" where messages are queued rather
than bounced. So the message to "a" sits in a queue somewhere but "b" sails
through.

Implementations have to deal with all of these issues and many more. Actual
delivery to the folder may be deferred until long after the script has
executed, making it effectively impossible to convert a delivery failure into a
script failure. And even if it is possible for fileinto, it isn't for
redirect, as you point out below.

> I expect that

> redirect "a@nosuchdomain";
> redirect "[e-mail]";

> may well send a message to "[e-mail]", despite the first
> causing a run-time error, because the action sets up the delivery of
> the message, but does not deliver it on its own.  But strictly
> speaking, this _is_ action reordering.  We need to say something about
> this topic.

I disagree. I don't think we have to discuss each and every thing we
don't prohibit.

> In case the second vacation causes an error: How would an example
> for that look like?

> While thinking about it: The base spec does not define if anyof and
> allof perform shortcut/lazy evaluation.  After all the years, all we can
> probably do is saying that depends on the implementation.  It should be
> mentioned, because it may cause the same script to behave different on
> different implementations.

It is mentioned to the extent that the spec says short circuit evaluation
is encouraged. I remain to be convinced that more is better here.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LHpqnF047450; Fri, 21 Oct 2005 10:51:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LHpq5L047449; Fri, 21 Oct 2005 10:51:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LHppxs047441 for <[e-mail]>; Fri, 21 Oct 2005 10:51:51 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 21 Oct 2005 10:51:49 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129917109; h=Date: 	 From:Subject:MIME-version:Content-type; b=KzPCgtrGJ9JIKqfuXtcyDCwOk 9QaPvKUXhWyZvQcyd9DhLcw7l9tfECqyB+orOe/0l3KOjyvUPQlZk8CUdJkJQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Oct 2005 10:51:47 -0700 (PDT)
Cc: Scott Hollenbeck <[e-mail]>, [e-mail]
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 21 Oct 2005 10:44:20 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Thu, 20 Oct 2005 15:58:35 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]>
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>

> On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> >
> > Section 4.7: "A script will fail if it attempts to execute two or more
> > vacation actions."
> > Should "will" be either SHOULD or MUST?  "will" describes an implementation
> > behavior.

> I also had a comment on 4.7 that I sent off-list.  Essentially:

>     I did wonder about that wording; seems to me that the the script as
>     a whole probably shouldn't fail, but the non-first vacation
>     action(s) should give an error.  i.e. duplication vacation actions
>     should fail, not abort the entire script.  (Not to mention that if
>     the script were to fail on the second "vacation" then there would be
>     no need to say "or more".)

I think this is an absolutely terrible idea. VIolations of the least
astonishment principle abound. Consider:

    vacation whatever1;
    vacation whatever2;
    if test {fileinto blah;}

If the test fails the script appears to work, sending one vacation response
but not the other. But if the test succeeds the script now fails for reasons
having nothing to do with the test. Such a gotcha can remain hidden
indefinitely only to go off when you least expect it - a script landmine.

Plenty of similar examples can be constructed but I think this is sufficient
to demonstrate that far from improving error handling, this makes a mess of it.

> Another nit was:

> > 5.8  In-Reply-To and References
>    >
>    > Section 3.6.2 of [RFC2822] provides a complete description of how
>    > References fields should be generated.

>    Pretty sure that's supposed to be section 3.6.4

Fixed.

> Plus some minor comment about the spelling of my name :-)

Sorry about that. Also fixed.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LHhgT9045260; Fri, 21 Oct 2005 10:43:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LHhgDh045259; Fri, 21 Oct 2005 10:43:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LHhe29045243 for <[e-mail]>; Fri, 21 Oct 2005 10:43:41 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 21 Oct 2005 10:43:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129916616; h=Date: 	 From:Subject:MIME-version:Content-type; b=ZuzHZaURvVr06AZ25AlAUsTTh 034RT2n733q7hVdGHlUHMm6xq1A60ODF/SV0+KVluOPjpCEpSvOBze2AQa2qg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Oct 2005 10:43:32 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Scott Hollenbeck <[e-mail]>, [e-mail]
To: Cyrus Daboo <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 21 Oct 2005 10:43:22 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Thu, 20 Oct 2005 15:46:19 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]>
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 Ned,

> --On October 20, 2005 10:44:36 AM -0700 Ned Freed <[e-mail]>
> wrote:

> >> First page:
> >> The "??" characters used for Tim's organization need to be replaced.  To
> >> be honest I'm not sure if anything should be used at all if there is no
> >> know organization.
> >
> > xml2rfc (incorrectly IMO - since we all participate as individuals, why
> > can't I be an entirely unaffiliated draft author?) insists on having an
> > organization field. I fired off a note to Tim asking him what he wants to
> > have there. Best I can do.

> I simply leave <organization/> as an empty element and that seems to do the
> right thing.

OK, I'll try that.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LD4EoT095005; Fri, 21 Oct 2005 06:04:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LD4E8n095004; Fri, 21 Oct 2005 06:04:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LD4DMT094976 for <[e-mail]>; Fri, 21 Oct 2005 06:04:13 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 21 Oct 2005 14:04:07 +0100
Message-ID: <[e-mail]>
Date: Fri, 21 Oct 2005 14:04:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Thu, Oct 20, 2005 at 07:30:47PM +0100, Alexey Melnikov wrote:
>  
>
>>>If I were to review such a draft, I would not accept it, unless the
>>>scheme name or overall syntax changed.
>>>      
>>>
>>Why? Extensions are the "IETF way".
>>    
>>
>
>Yes, but extensions need to be recognized as such.  Sieve uses "require",
>which I like a lot.  URIs start with the scheme, and having two schemes
>with the same name, one being a superset of the other, sounds very odd
>to me.
>  
>
This is one reason why I suggest to have separate notification method 
profiles. Each profile will define which extensions to a particular URI 
scheme must be supported by the notification method.

>>You are trying to work around process issues by using different syntax. 
>>I think such approach is wrong.
>>We shouldn't talk about this unless it becomes a problem.   
>>
>Ok.  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LAdOpG066677; Fri, 21 Oct 2005 03:39:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LAdOQN066676; Fri, 21 Oct 2005 03:39:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LAdNW3066660 for <[e-mail]>; Fri, 21 Oct 2005 03:39:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESuJ0-0007RO-Q4 for [e-mail]; Fri, 21 Oct 2005 12:39:22 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESuJ0-0000Pp-M6 for [e-mail]; Fri, 21 Oct 2005 12:39:22 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESuJ0-00073c-Dn for [e-mail]; Fri, 21 Oct 2005 12:39:22 +0200
Date: Fri, 21 Oct 2005 12:39:22 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Fri, Oct 21, 2005 at 02:45:34AM +0200, Kjetil Torgrim Homme wrote:
> On Fri, 2005-10-21 at 01:22 +0200, Michael Haardt wrote:
> > While thinking about it: The base spec does not define if anyof and
> > allof perform shortcut/lazy evaluation.  After all the years, all we can
> > probably do is saying that depends on the implementation.  It should be
> > mentioned, because it may cause the same script to behave different on
> > different implementations.
> 
> well, in 3028 tests cannot have side effects, so it isn't possible to
> tell.  this restriction has been lifted to allow for the match variables
> in variables, and that draft says:
> 
>    The interpreter MUST short-circuit tests, ie. not perform more tests
>    than necessary to find the result.  Evaluation order MUST be left to
>    right.  If a test has two or more list arguments, the implementation
>    is free to choose which to iterate over first.
> 
> however, the future may bring other extensions which introduce tests
> with side effects, so I guess it could be nice to have the above
> clarification in the base spec, although conformance is not observable
> with the base spec alone.

No, it is.  From section 2.6.10, Errors:

   Implementations MUST perform syntactic, semantic, and run-time checks
   on code that is actually executed.  Implementations MAY perform those
   checks or any part of them on code that is not reached during
   execution.

That means, "anyof" with one semantically valid test, that evaluates to
true, and one semantically invalid test, will evaluate to true, if using
shortcut evaluation and lazy checks, and generate an error with strict
evaluation or strict checks.

You mentioned another point: Evaluation order.  Indeed that is not
specified either, and it can be observed as well.

I would like to see short-cut evaluation and evaluation order from
left to right in the base spec, but I am not sure if we can do that.
It is an incompatible change.  Oops, I said the i-word.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LATHQg064494; Fri, 21 Oct 2005 03:29:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LATH0Y064493; Fri, 21 Oct 2005 03:29:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LATGlI064486 for <[e-mail]>; Fri, 21 Oct 2005 03:29:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESu9D-0004ij-A6 for [e-mail]; Fri, 21 Oct 2005 12:29:15 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESu9D-0005qS-2N for [e-mail]; Fri, 21 Oct 2005 12:29:15 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESu9B-00072y-50 for [e-mail]; Fri, 21 Oct 2005 12:29:13 +0200
Date: Fri, 21 Oct 2005 12:29:13 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: status of 3028bis
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Fri, Oct 21, 2005 at 02:38:29AM +0200, Kjetil Torgrim Homme wrote:
>    The "en;ascii-casemap" collation is a simple collation intended for
>    use with English language text in pure US-ASCII.  It provides
>    equality, substring and ordering functions.  The algorithm first
>    applies a canonicalization algorithm to both input strings which
>    subtracts 32 (0x20) from all octet values between 97 (0x61) and 122
>    (0x7A) inclusive.  The result of the collation is then the same as
>    the result of the "i;octet" collation for the canonicalized strings.
> 
> (the algorithm in RFC 2244 is essentially the same.)
> 
> this was surprising and interesting to me, since it means that with
> "abc" :matches "ab?", ${1} will hold the uppercase "C"!  I wonder how
> many users would expect that one, or how many implementations get it
> right.

Oh my god.  Basically, this means a Sieve implementation does not
know anything about its input being UTF8.  All it does is converting
headers to UTF8, but other than that, it works on octets, not characters.

If so, we must not talk about unicode, but UTF8, and s/character/octet/g.
And I have to change my implementation, which works on characters,
crippling it.

Do all implementations else work on octets instead of characters?

> > Are you saying that even using "en;ascii-casemap", the wildcard "?"
> > does not match a single character outside US-ASCII?
> 
> since the spec defines it in terms of i;octet, the "?" wildcard is
> essentially broken.  it gets really interesting with "*", though, since
> you will probably get doubly encoded UTF-8 :-(

Worse, matched octets can be invalid (incomplete) UTF8 octet-sequences.
You gave an example how variables extract a single octet of a sequence,
and you can't even control if ? matches an incomplete UTF8 octet-sequence
or a US-ASCII character: You can not use the matched part to modify or
generate mails or you risk to ruin the result.

> this is truly a mess.  we need a comparator which makes sense, a
> comparator which operates case-fully on Unicode characters, but without
> the difficult bits (e.g. normalising combining characters).

Indeed!

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L8dqGu041320; Fri, 21 Oct 2005 01:39:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9L8dqI9041319; Fri, 21 Oct 2005 01:39:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L8dpKs041309 for <[e-mail]>; Fri, 21 Oct 2005 01:39:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESsRJ-0001i6-SH for [e-mail]; Fri, 21 Oct 2005 10:39:49 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1ESsRE-0003n3-6o for [e-mail]; Fri, 21 Oct 2005 10:39:46 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESsQj-0006yi-1a for [e-mail]; Fri, 21 Oct 2005 10:39:13 +0200
Date: Fri, 21 Oct 2005 10:39:13 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <1129852692.15490.160.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1129852692.15490.160.camel@localhost>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 20, 2005 at 04:58:12PM -0700, Aaron Stone wrote:
> On Fri, 2005-10-21 at 01:22 +0200, Michael Haardt wrote:
> > I expect that
> > 
> > redirect "a@nosuchdomain";
> > redirect "[e-mail]";
> > 
> > may well send a message to "[e-mail]", despite the first
> > causing a run-time error, because the action sets up the delivery of
> > the message, but does not deliver it on its own.  But strictly
> > speaking, this _is_ action reordering.  We need to say something about
> > this topic.
> 
> I don't believe this is action reordering. What you're presupposing is
> that the message is redirected in an asynchronous manner (as is
> reasonable in any modern mail system), but then you're broadly
> redefining the out-of-order _results_ as action reordering.

As I said, with mails, this behaviour is expected.  In common programming
languages, statements are executed strictly sequential, including all
side effects and exceptions from that rule are specified in great detail.

Your suggestion to look at results (external side effects) may be the
solution.  I suggest:

  With regard to side effects on the state of the Sieve machine, all
  commands are processed strictly sequential, but side effects outside the
  Sieve machine, such as filed or redirected mails, MAY happen out of order.
  Run time errors on external side effects MAY not have any influence on
  the Sieve machine.

Now all we need may be putting that into words that can be understood. ;-)

The MAY tries to say that this is yet another place where the same script
may yield different results on different systems.  Improvements are more
than welcome.

Since the second vacation command has the side effect of generating an
error inside the Sieve machine (internal side effect), execution must
stop exactly there.  A fileinto afterwards will never be executed, if
we agree on the above behaviour.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L2kp37094184; Thu, 20 Oct 2005 19:46:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9L2kpYT094183; Thu, 20 Oct 2005 19:46:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L2kp8L094177 for <[e-mail]>; Thu, 20 Oct 2005 19:46:51 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 505B6608EF69; Thu, 20 Oct 2005 19:46:48 -0700 (PDT)
Received: from [192.168.0.6] (dsl3-63-249-106-198.cruzio.com [63.249.106.198]) by lucite.serendipity.cx (Postfix) with ESMTP id 91B4B608EF67; Thu, 20 Oct 2005 19:46:43 -0700 (PDT)
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
From: Aaron Stone <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 20 Oct 2005 16:58:12 -0700
Message-Id: <1129852692.15490.160.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43585698272468432729595!
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>

On Fri, 2005-10-21 at 01:22 +0200, Michael Haardt wrote:
> I expect that
> 
> redirect "a@nosuchdomain";
> redirect "[e-mail]";
> 
> may well send a message to "[e-mail]", despite the first
> causing a run-time error, because the action sets up the delivery of
> the message, but does not deliver it on its own.  But strictly
> speaking, this _is_ action reordering.  We need to say something about
> this topic.

I don't believe this is action reordering. What you're presupposing is
that the message is redirected in an asynchronous manner (as is
reasonable in any modern mail system), but then you're broadly
redefining the out-of-order _results_ as action reordering.

Aaron




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L0jlCa083147; Thu, 20 Oct 2005 17:45:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9L0jlip083146; Thu, 20 Oct 2005 17:45:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L0jkEC083126 for <[e-mail]>; Thu, 20 Oct 2005 17:45:47 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1ESl2V-0006hl-Ac; Fri, 21 Oct 2005 02:45:43 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ESl2S-0007zd-T8; Fri, 21 Oct 2005 02:45:40 +0200
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 21 Oct 2005 02:45:34 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.457, required 12, autolearn=disabled, AWL 1.36, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Fri, 2005-10-21 at 01:22 +0200, Michael Haardt wrote:
> While thinking about it: The base spec does not define if anyof and
> allof perform shortcut/lazy evaluation.  After all the years, all we can
> probably do is saying that depends on the implementation.  It should be
> mentioned, because it may cause the same script to behave different on
> different implementations.

well, in 3028 tests cannot have side effects, so it isn't possible to
tell.  this restriction has been lifted to allow for the match variables
in variables, and that draft says:

   The interpreter MUST short-circuit tests, ie. not perform more tests
   than necessary to find the result.  Evaluation order MUST be left to
   right.  If a test has two or more list arguments, the implementation
   is free to choose which to iterate over first.

however, the future may bring other extensions which introduce tests
with side effects, so I guess it could be nice to have the above
clarification in the base spec, although conformance is not observable
with the base spec alone.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L0cheX082546; Thu, 20 Oct 2005 17:38:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9L0chp9082545; Thu, 20 Oct 2005 17:38:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9L0cgG1082537 for <[e-mail]>; Thu, 20 Oct 2005 17:38:43 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1ESkve-0005kH-Su; Fri, 21 Oct 2005 02:38:39 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ESkvc-0001RL-4t; Fri, 21 Oct 2005 02:38:36 +0200
Subject: Re: status of 3028bis
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 21 Oct 2005 02:38:29 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.635, required 12, autolearn=disabled, AWL 1.18, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Fri, 2005-10-21 at 00:03 +0200, Michael Haardt wrote:
> On Thu, Oct 20, 2005 at 07:44:05PM +0100, Dave Cridland wrote:
> > We need to restrict this discussion to just the one mailing list, 
> > really, but I've posted a message saying that actually, the reverse 
> > is true - comparators match on octet strings, and happen to have a 
> > decode built in - hence i;octet doesn't decode, and i;ascii-* both 
> > decode using ASCII.
> 
> What exactly do you mean by "decode"? Removing the MIME encoding or
> converting the character set?

I'm not Dave, but I would mean "decode UTF-8 octet sequences to Unicode
characters".  RFC 2047 and RFC 2231 decoding will always be done.  BTW,
the draft does not mention RFC 2231 at all, I think that should be more
explicit, since it has explicit references to RFC 2047.

> > The notion that comparators work on character strings is a notion 
> > that comes pre-flawed - ACAP does not operate on character strings, 
> > but octet strings, which might on a good day happen to be UTF-8 
> > encoded text, but might be anything.
> 
> That explains why we have that mess.  Over here, users certainly expect
> "en;ascii-case" to match characters, and will be confused if the first
> test is true and the second is not, and yet more, if both are false:
> 
> Subject: =?utf8?q?A=c3=a4?=
> 
> :comparator "en;ascii-casemap" :matches "a?"

no.  if you change the pattern to "a?*", and have variables, ${1} would
hold U+00C3 (not U+00E4, the decoded value).

> :comparator "i;octet" :matches "A?"

no.  same as above.

> If "i;octet" operates on octets, we can't talk of unicode, but need
> to talk about UTF8 for comparisons, and users will ask instantly:
> How can I match characters case sensitive? The base spec makes me think
> "i;octet" is just that, and operating on characters, despite the name.

well, to me it is quite obvious that when it says "octet", it doesn't
support multibyte encodings, but rather operates on raw byte values.
RFC 2244 is quite explicit:

     For collation, the i;octet comparator interprets the value of
     an attribute as a series of unsigned octets with ordinal
     values from 0 to 255.

the base spec does not support caseful matching where "?" makes sense in
non-ASCII.  in fact, the latest comparator draft I can find doesn't
provide one either.  the algorithm for en;ascii-casemap is quite
amusing:

   The "en;ascii-casemap" collation is a simple collation intended for
   use with English language text in pure US-ASCII.  It provides
   equality, substring and ordering functions.  The algorithm first
   applies a canonicalization algorithm to both input strings which
   subtracts 32 (0x20) from all octet values between 97 (0x61) and 122
   (0x7A) inclusive.  The result of the collation is then the same as
   the result of the "i;octet" collation for the canonicalized strings.

(the algorithm in RFC 2244 is essentially the same.)

this was surprising and interesting to me, since it means that with
"abc" :matches "ab?", ${1} will hold the uppercase "C"!  I wonder how
many users would expect that one, or how many implementations get it
right.

> Section 2.7.1, Match Type, does not mention octets anywhere.
> 
> > I've also suggested that where all the protocol has is a character 
> > string, then the semantics of a comparator must behave as though the 
> > string were encoded using UTF-8 (possibly by actually doing so).
> 
> Are you saying that even using "en;ascii-casemap", the wildcard "?"
> does not match a single character outside US-ASCII?

since the spec defines it in terms of i;octet, the "?" wildcard is
essentially broken.  it gets really interesting with "*", though, since
you will probably get doubly encoded UTF-8 :-(

this is truly a mess.  we need a comparator which makes sense, a
comparator which operates case-fully on Unicode characters, but without
the difficult bits (e.g. normalising combining characters).

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KNMDDk073239; Thu, 20 Oct 2005 16:22:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KNMDVq073238; Thu, 20 Oct 2005 16:22:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KNMC24073231 for <[e-mail]>; Thu, 20 Oct 2005 16:22:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESjjf-00077D-GP for [e-mail]; Fri, 21 Oct 2005 01:22:11 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESjjf-0005Hu-Dn for [e-mail]; Fri, 21 Oct 2005 01:22:11 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESjjc-0006oe-Tc for [e-mail]; Fri, 21 Oct 2005 01:22:08 +0200
Date: Fri, 21 Oct 2005 01:22:08 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 20, 2005 at 03:58:35PM -0400, Mark E. Mallett wrote:
> 
> On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> > 
> > Section 4.7: "A script will fail if it attempts to execute two or more
> > vacation actions."
> > Should "will" be either SHOULD or MUST?  "will" describes an implementation
> > behavior.
> 
> I also had a comment on 4.7 that I sent off-list.  Essentially:
> 
>     I did wonder about that wording; seems to me that the the script as
>     a whole probably shouldn't fail, but the non-first vacation
>     action(s) should give an error.  i.e. duplication vacation actions
>     should fail, not abort the entire script.  (Not to mention that if
>     the script were to fail on the second "vacation" then there would be
>     no need to say "or more".)

The base spec says:

   When an error occurs in a Sieve script, all processing stops.

So either you ignore vacation actions starting at the second one, or
you generate an error.  If an error is generated, all processing stops.
If so, indeed there can't be a third.

I'd say, let's include an example showing two vacation actions and
a fileinto afterwards, stating the fileinto can not happen (assuming
the second vacation action does generate an error), but:

Does the base spec allow action execution reordering?

That's not as crazy as it sounds.  Of course actions with side effects
must not be reordered, that goes without saying.  And how about actions
without side effects?

fileinto "a";
fileinto "b";

If a message is filed to "b", will there be one in "a", or could
both actions be processed simultaneous after the script ran, "a"
fails with a runtime error and "b" suceeds?

I expect that

redirect "a@nosuchdomain";
redirect "[e-mail]";

may well send a message to "[e-mail]", despite the first
causing a run-time error, because the action sets up the delivery of
the message, but does not deliver it on its own.  But strictly
speaking, this _is_ action reordering.  We need to say something about
this topic.

In case the second vacation causes an error: How would an example
for that look like?

While thinking about it: The base spec does not define if anyof and
allof perform shortcut/lazy evaluation.  After all the years, all we can
probably do is saying that depends on the implementation.  It should be
mentioned, because it may cause the same script to behave different on
different implementations.

Oh well.

> Another nit was:
> 
> > 5.8  In-Reply-To and References
>    >
>    > Section 3.6.2 of [RFC2822] provides a complete description of how
>    > References fields should be generated.
> 
>    Pretty sure that's supposed to be section 3.6.4

I agree.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KM3G0k066410; Thu, 20 Oct 2005 15:03:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KM3G9d066409; Thu, 20 Oct 2005 15:03:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KM3F9c066402 for <[e-mail]>; Thu, 20 Oct 2005 15:03:15 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESiVG-0001wb-Dm for [e-mail]; Fri, 21 Oct 2005 00:03:14 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1ESiVG-0007pc-CV for [e-mail]; Fri, 21 Oct 2005 00:03:14 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESiVD-0006nR-Ql for [e-mail]; Fri, 21 Oct 2005 00:03:11 +0200
Date: Fri, 21 Oct 2005 00:03:11 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: status of 3028bis
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 20, 2005 at 07:44:05PM +0100, Dave Cridland wrote:
> We need to restrict this discussion to just the one mailing list, 
> really, but I've posted a message saying that actually, the reverse 
> is true - comparators match on octet strings, and happen to have a 
> decode built in - hence i;octet doesn't decode, and i;ascii-* both 
> decode using ASCII.

What exactly do you mean by "decode"? Removing the MIME encoding or
converting the character set?

> The notion that comparators work on character strings is a notion 
> that comes pre-flawed - ACAP does not operate on character strings, 
> but octet strings, which might on a good day happen to be UTF-8 
> encoded text, but might be anything.

That explains why we have that mess.  Over here, users certainly expect
"en;ascii-case" to match characters, and will be confused if the first
test is true and the second is not, and yet more, if both are false:

Subject: =?utf8?q?A=c3=a4?=

:comparator "en;ascii-casemap" :matches "a?"
:comparator "i;octet" :matches "A?"

If "i;octet" operates on octets, we can't talk of unicode, but need
to talk about UTF8 for comparisons, and users will ask instantly:
How can I match characters case sensitive? The base spec makes me think
"i;octet" is just that, and operating on characters, despite the name.
Section 2.7.1, Match Type, does not mention octets anywhere.

> I've also suggested that where all the protocol has is a character 
> string, then the semantics of a comparator must behave as though the 
> string were encoded using UTF-8 (possibly by actually doing so).

Are you saying that even using "en;ascii-casemap", the wildcard "?"
does not match a single character outside US-ASCII?

Alexey: No matter how this turns out, could we add the above example
including the result to the base spec?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KLNo4N062718; Thu, 20 Oct 2005 14:23:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KLNoZ1062716; Thu, 20 Oct 2005 14:23:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KLNnq5062706 for <[e-mail]>; Thu, 20 Oct 2005 14:23:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESht6-0000At-DR for [e-mail]; Thu, 20 Oct 2005 23:23:48 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESht6-0001Z5-Bs for [e-mail]; Thu, 20 Oct 2005 23:23:48 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESht6-0006ls-61 for [e-mail]; Thu, 20 Oct 2005 23:23:48 +0200
Date: Thu, 20 Oct 2005 23:23:48 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 20, 2005 at 07:30:47PM +0100, Alexey Melnikov wrote:
> >If I were to review such a draft, I would not accept it, unless the
> >scheme name or overall syntax changed.
> >
> Why? Extensions are the "IETF way".

Yes, but extensions need to be recognized as such.  Sieve uses "require",
which I like a lot.  URIs start with the scheme, and having two schemes
with the same name, one being a superset of the other, sounds very odd
to me.

> You are trying to work around process issues by using different syntax. 
> I think such approach is wrong.
> We shouldn't talk about this unless it becomes a problem.

Ok.

> 1). The WG needs to evaluate if mailto: is indeed appropriate.

Up to now, it is.  I have a bad feeling that may change, and gave some
examples of options I don't need, but which would mean a dead end to
URI extension, if I did.

> 2). credentials, message transmission modes and submission server host 
> seem like a configuration issue (unless you want each user to 
> authenticate as the receiver of the message), I don't think they should 
> be mentioned in a Sieve script.

Suppose a SMTP to SMS gateway requires authentication, because it bills
your messages, then you needed ways to specify the credentials and
the gateway host.  But that's just imagination.  All gateways I know
work by having the recipient, not the sender, paying for the message.

Should this turn from imagination to reality, it could look like:

  notify :method "mailto:number@gateway"
         :options ["login=me","secret=geheim","transmission=encrypted"];

Using :options sounds better than :attributes to me.

I am currently building a list of German SMTP->SMS gateways to know better
what exactly they require and offer.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJwbBr053515; Thu, 20 Oct 2005 12:58:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KJwbao053514; Thu, 20 Oct 2005 12:58:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9KJwZq3053496 for <[e-mail]>; Thu, 20 Oct 2005 12:58:36 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 98256 invoked by uid 101); 20 Oct 2005 15:58:35 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 20 Oct 2005 15:58:35 -0400
To: Scott Hollenbeck <[e-mail]>
Cc: [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
> 
> Section 4.7: "A script will fail if it attempts to execute two or more
> vacation actions."
> Should "will" be either SHOULD or MUST?  "will" describes an implementation
> behavior.

I also had a comment on 4.7 that I sent off-list.  Essentially:

    I did wonder about that wording; seems to me that the the script as
    a whole probably shouldn't fail, but the non-first vacation
    action(s) should give an error.  i.e. duplication vacation actions
    should fail, not abort the entire script.  (Not to mention that if
    the script were to fail on the second "vacation" then there would be
    no need to say "or more".)


Another nit was:

> 5.8  In-Reply-To and References
   >
   > Section 3.6.2 of [RFC2822] provides a complete description of how
   > References fields should be generated.

   Pretty sure that's supposed to be section 3.6.4


Plus some minor comment about the spelling of my name :-)

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJo7XW052651; Thu, 20 Oct 2005 12:50:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KJo7mA052650; Thu, 20 Oct 2005 12:50:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJo6Ff052643 for <[e-mail]>; Thu, 20 Oct 2005 12:50:06 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 20 Oct 2005 15:50:05 -0400 id 005D02B6.4357F4ED.0000483A
From: "Scott Hollenbeck" <[e-mail]>
To: "'Ned Freed'" <[e-mail]>
Cc: [e-mail]
Subject: RE: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Date: Thu, 20 Oct 2005 15:50:11 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
Thread-Index: AcXVoPtyL73nzx4YQHa5dImc20sYagADZ6og
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[e-mail]>
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>

Thoughts below.

> -----Original Message-----
> From: Ned Freed [mailto:[e-mail]] 
> Sent: Thursday, October 20, 2005 1:45 PM
> To: Scott Hollenbeck
> Cc: [e-mail]
> Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
> 
> > Some questions and comments, also noted in the I-D Tracker. 
>  Please clue me
> > in as appropriate:
> 
> > Minor IDNit errors are noted in the tracker.  The shepherd 
> write-up said
> > that IDNits ran cleanly.  Hmm...
> 
> The two nits appear to be additional spaces between words. 
> I've removed them.
> (For the record, I think this is a stupid and unnecessary 
> check for idnits to
> make, especially since the vagarities of line breaking can 
> create situations
> where extra space lurks indefinitely in a document.)

Agreed.  As I said in a private note to Cyrus, his write-up said that the
nits checker ran cleanly.  I wasn't sure if that meant that he didn't see
this little warnings, or if they didn't pop up.  No big deal.

> > General comment: both "Sieve" and "sieve" are used in the 
> document.  One
> > form or the other should be used consistently.
> 
> It's a proper name for a language so "Sieve" would appear to 
> be the better
> choice (except in file names, of course). Fixed.
> 
> > First page:
> > The "??" characters used for Tim's organization need to be 
> replaced.  To be
> > honest I'm not sure if anything should be used at all if 
> there is no know
> > organization.
> 
> xml2rfc (incorrectly IMO - since we all participate as 
> individuals, why can't I
> be an entirely unaffiliated draft author?) insists on having 
> an organization
> field. I fired off a note to Tim asking him what he wants to 
> have there. Best
> I can do.

Would quoted blanks work?  I've never tried myself.

> > Section 4.1:
> > I'm curious about the "Sites MAY also define a maximum days 
> value, which
> > MUST be greater than 7, and SHOULD be greater than 30" 
> text.  Why use a MUST
> > for what appears to be an operational matter?  What is the impact on
> > interoperability if a lesser value is used?
> 
> Simple: In order to write portable scripts there needs to be 
> some guarantee as
> to how big a :days value you can specify. This requirement 
> means a script that
> specifies a value of 7 or less is guaranteed to run on any 
> compliant Sieve
> system that supports vacation. Without this requirement you 
> don't have such a
> guarantee.
> 
> > Section 4.2:  "Implementations are free to limit the number 
> of remembered
> > responses, provided the limit is no less than 1000."
> > Why 1000, and is this a normative requirement or not?
> 
> 1000 seemed like a reasonable value. It is no more justified 
> (or justifiable)
> than, say, the 1000 character line length limit in SMTP.
> 
> I'll make the language normative.
> 
> > Section 4.7: "A script will fail if it attempts to execute 
> two or more
> > vacation actions."
> > Should "will" be either SHOULD or MUST?  "will" describes 
> an implementation
> > behavior.
> 
> I'll make it a MUST.

OK, I'm satisfied.  There's nothing serious enough to warrant revision
before the last call.  Queue them up for processing along with anything else
that comes up.

Thanks for the quick response,
-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJkNt8052401; Thu, 20 Oct 2005 12:46:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KJkNju052400; Thu, 20 Oct 2005 12:46:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJkMRc052392 for <[e-mail]>; Thu, 20 Oct 2005 12:46:22 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.2] (port99.educause216.ucf.edu [132.170.216.100]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j9KJdXuG023277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 15:39:35 -0400
Date: Thu, 20 Oct 2005 15:46:19 -0400
From: Cyrus Daboo <[e-mail]>
To: Ned Freed <[e-mail]>, Scott Hollenbeck <[e-mail]>
cc: [e-mail]
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
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 Ned,

--On October 20, 2005 10:44:36 AM -0700 Ned Freed <[e-mail]> 
wrote:

>> First page:
>> The "??" characters used for Tim's organization need to be replaced.  To
>> be honest I'm not sure if anything should be used at all if there is no
>> know organization.
>
> xml2rfc (incorrectly IMO - since we all participate as individuals, why
> can't I be an entirely unaffiliated draft author?) insists on having an
> organization field. I fired off a note to Tim asking him what he wants to
> have there. Best I can do.

I simply leave <organization/> as an empty element and that seems to do the 
right thing.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJVUfU051322; Thu, 20 Oct 2005 12:31:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KJVUn0051321; Thu, 20 Oct 2005 12:31:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KJVTgO051314 for <[e-mail]>; Thu, 20 Oct 2005 12:31:29 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 20 Oct 2005 12:31:28 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129836687; h=Date: 	 From:Subject:MIME-version:Content-type; b=a2slwz5Ayw3bT7R+ouv+ePSoV AQ2sSBJTmU6W5xmwoxHd9ReZ6afzO0uiSBq5DdWcm7WTp3gHEcwmLXw0FTEDw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 20 Oct 2005 12:31:25 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>, Michael Haardt <[e-mail]>
To: Dave Cridland <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 20 Oct 2005 12:27:43 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: status of 3028bis
In-reply-to: "Your message dated Thu, 20 Oct 2005 19:44:05 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Thu Oct 20 14:59:04 2005, Alexey Melnikov wrote:
> >
> > Michael Haardt wrote:
> >
> >> On Tue, Oct 18, 2005 at 02:06:00PM -0700, Philip Guenther wrote:
> >>
> >>> In particular, there's some uncertainty
> >>> over whether comparators take octets or characters as input and
> >>> how
> >>> i;octet is defined and used in the definition of other
> >>> comparators.
> >>>
> > [...]
> >
> >> Let "i;octet" work on characters and document the name is a
> >> misnomer.
> >>
> >> IF someone really feels the need to specify and implement them:
> >> Introduce
> >> Sieve extensions for a "i;binary" comparator that compares against
> >> a
> >> string representation of binary data.  Introduce new tests
> >> "rawheader"
> >> and "decodedheader".
> >>
> >> I am not aware how "i;octet" is used at other places, so the above
> >> may
> >> only fit well to Sieve.
> >>
> > Your suggestion make sense for header fields. But what about body
> > extension when matching against application/* MIME part?
> >
> >
> We need to restrict this discussion to just the one mailing list,
> really, but I've posted a message saying that actually, the reverse
> is true - comparators match on octet strings, and happen to have a
> decode built in - hence i;octet doesn't decode, and i;ascii-* both
> decode using ASCII.

Wow, I'm sure glad you said this, because this has always been my
interpretation as well, and I was getting the idea I was all alone in seeing it
this way. It definitely is how our implementation works too.

> The notion that comparators work on character strings is a notion
> that comes pre-flawed - ACAP does not operate on character strings,
> but octet strings, which might on a good day happen to be UTF-8
> encoded text, but might be anything.

Yep.

> I've also suggested that where all the protocol has is a character
> string, then the semantics of a comparator must behave as though the
> string were encoded using UTF-8 (possibly by actually doing so).

But not necessarily by doing so. In many cases it is more convenient to decode
to a fixed-length representation like UTF-32. The behavior is what matters, not
the implementation details.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KIiGcE045642; Thu, 20 Oct 2005 11:44:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KIiGbW045641; Thu, 20 Oct 2005 11:44:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.dave.cridland.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KIiF5u045631 for <[e-mail]>; Thu, 20 Oct 2005 11:44:15 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 446A6154009; Thu, 20 Oct 2005 18:44:07 +0000 (UTC)
Date: Thu, 20 Oct 2005 19:44:05 +0100
Subject: Re: status of 3028bis
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>, Michael Haardt <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

On Thu Oct 20 14:59:04 2005, Alexey Melnikov wrote:
> 
> Michael Haardt wrote:
> 
>> On Tue, Oct 18, 2005 at 02:06:00PM -0700, Philip Guenther wrote:
>>  
>>> In particular, there's some uncertainty
>>> over whether comparators take octets or characters as input and 
>>> how
>>> i;octet is defined and used in the definition of other 
>>> comparators.
>>>    
> [...]
> 
>> Let "i;octet" work on characters and document the name is a 
>> misnomer.
>> 
>> IF someone really feels the need to specify and implement them: 
>> Introduce
>> Sieve extensions for a "i;binary" comparator that compares against 
>> a
>> string representation of binary data.  Introduce new tests 
>> "rawheader"
>> and "decodedheader".
>> 
>> I am not aware how "i;octet" is used at other places, so the above 
>> may
>> only fit well to Sieve.
>>  
> Your suggestion make sense for header fields. But what about body 
> extension when matching against application/* MIME part?
> 
> 
We need to restrict this discussion to just the one mailing list, 
really, but I've posted a message saying that actually, the reverse 
is true - comparators match on octet strings, and happen to have a 
decode built in - hence i;octet doesn't decode, and i;ascii-* both 
decode using ASCII.

The notion that comparators work on character strings is a notion 
that comes pre-flawed - ACAP does not operate on character strings, 
but octet strings, which might on a good day happen to be UTF-8 
encoded text, but might be anything.

I've also suggested that where all the protocol has is a character 
string, then the semantics of a comparator must behave as though the 
string were encoded using UTF-8 (possibly by actually doing so).

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KIXCBq044542; Thu, 20 Oct 2005 11:33:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KIXCCF044541; Thu, 20 Oct 2005 11:33:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KIXB8k044534 for <[e-mail]>; Thu, 20 Oct 2005 11:33:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.182] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 20 Oct 2005 19:30:48 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Oct 2005 19:30:47 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>>>If I simply let notify understand SMS URIs with the parameter "route",
>>>the URI will violate the officially specified URI definition.  Possible,
>>>but almost correct just isn't.
>>>      
>>>
>>One can write a new draft extending an existing URI scheme.
>>    
>>
>
>If I were to review such a draft, I would not accept it, unless the
>scheme name or overall syntax changed.
>
Why? Extensions are the "IETF way".

>Something like Exim's URIs
>that begin with attribute-value pairs, separated by white space
>and followed by the URI is fine.
>
>If the editor of an URI scheme refuses to change it,
>
I am not sure if you are talking about editor having good reasons for 
saying "no" or just being an asshole.
Unless the draft has "no derivative work" IPR statement, the editor 
doesn't have total control over the document and other people can 
publish independent documents based on it.

>or if the revision
>process takes too long, I think that should be accepted and ways to pass
>information not in, but next to the URI, should be chosen.
>  
>
You are trying to work around process issues by using different syntax. 
I think such approach is wrong.
We shouldn't talk about this unless it becomes a problem.

>>>Change all concerned URI schemes?
>>>      
>>>
>>So far we've identified only 3, I don't think it would be too hard. I 
>>don't think anybody is proposing to examine all standardized URI types.
>>    
>>
>
>I have little to no experience in that area.  If you think changing xmpp
>(sp?), sms and mailto could be changed, I am more than willing to forget
>about tagged arguments mapped to URI parameters, attribute-value pairs
>and the like.
>  
>
I can't give any general case answer to this question unless I see a 
list of desired options. But in general I see no problems with extending 
URI syntaxes.

>Changing the mailto URI is troublesome, because it contains one namespace
>for both headers and other parameters.  If someone introduced a new header
>field called "Body", it would fail badly.  You can't specify credentials,
>message transmission modes or even the smart host to use, and you can't
>add any of that, because it would conflict with header names.
>
Two comments:
1). The WG needs to evaluate if mailto: is indeed appropriate.
2). credentials, message transmission modes and submission server host 
seem like a configuration issue (unless you want each user to 
authenticate as the receiver of the message), I don't think they should 
be mentioned in a Sieve script.

>Up to now, all I have trouble with are the security considerations and their
>consequences.  Should that ever change and new parameters are required,
>that route is a dead end.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KI6MJx041574; Thu, 20 Oct 2005 11:06:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KI6MHm041573; Thu, 20 Oct 2005 11:06:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KI6LEX041566 for <[e-mail]>; Thu, 20 Oct 2005 11:06:21 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 20 Oct 2005 11:06:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129831578; h=Date: 	 From:Subject:MIME-version:Content-type; b=SYDiDWg0WZKjPiXzZZCT8ODBY ejbreEymsRjUJE+X5Q4h6gj5Nz/USFZN0pCdzO7DEzFSkfjaJfvH4h+lGh+NQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 20 Oct 2005 11:06:16 -0700 (PDT)
Cc: [e-mail]
To: Scott Hollenbeck <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 20 Oct 2005 10:44:36 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
In-reply-to: "Your message dated Thu, 20 Oct 2005 13:20:07 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]>
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>

> Some questions and comments, also noted in the I-D Tracker.  Please clue me
> in as appropriate:

> Minor IDNit errors are noted in the tracker.  The shepherd write-up said
> that IDNits ran cleanly.  Hmm...

The two nits appear to be additional spaces between words. I've removed them.
(For the record, I think this is a stupid and unnecessary check for idnits to
make, especially since the vagarities of line breaking can create situations
where extra space lurks indefinitely in a document.)

> General comment: both "Sieve" and "sieve" are used in the document.  One
> form or the other should be used consistently.

It's a proper name for a language so "Sieve" would appear to be the better
choice (except in file names, of course). Fixed.

> First page:
> The "??" characters used for Tim's organization need to be replaced.  To be
> honest I'm not sure if anything should be used at all if there is no know
> organization.

xml2rfc (incorrectly IMO - since we all participate as individuals, why can't I
be an entirely unaffiliated draft author?) insists on having an organization
field. I fired off a note to Tim asking him what he wants to have there. Best
I can do.

> Section 4.1:
> I'm curious about the "Sites MAY also define a maximum days value, which
> MUST be greater than 7, and SHOULD be greater than 30" text.  Why use a MUST
> for what appears to be an operational matter?  What is the impact on
> interoperability if a lesser value is used?

Simple: In order to write portable scripts there needs to be some guarantee as
to how big a :days value you can specify. This requirement means a script that
specifies a value of 7 or less is guaranteed to run on any compliant Sieve
system that supports vacation. Without this requirement you don't have such a
guarantee.

> Section 4.2:  "Implementations are free to limit the number of remembered
> responses, provided the limit is no less than 1000."
> Why 1000, and is this a normative requirement or not?

1000 seemed like a reasonable value. It is no more justified (or justifiable)
than, say, the 1000 character line length limit in SMTP.

I'll make the language normative.

> Section 4.7: "A script will fail if it attempts to execute two or more
> vacation actions."
> Should "will" be either SHOULD or MUST?  "will" describes an implementation
> behavior.

I'll make it a MUST.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KHK59N036855; Thu, 20 Oct 2005 10:20:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KHK5nJ036854; Thu, 20 Oct 2005 10:20:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KHK42Z036847 for <[e-mail]>; Thu, 20 Oct 2005 10:20:04 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 20 Oct 2005 13:20:01 -0400 id 005D0294.4357D1C1.0000237C
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: AD Evaluation Comments: draft-ietf-sieve-vacation-04
Date: Thu, 20 Oct 2005 13:20:07 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcXVmoSeMFvcyL+GSZaAirQ7lGMpfg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[e-mail]>
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>

Some questions and comments, also noted in the I-D Tracker.  Please clue me
in as appropriate:

Minor IDNit errors are noted in the tracker.  The shepherd write-up said
that IDNits ran cleanly.  Hmm...

General comment: both "Sieve" and "sieve" are used in the document.  One
form or the other should be used consistently.

First page:
The "??" characters used for Tim's organization need to be replaced.  To be
honest I'm not sure if anything should be used at all if there is no know
organization.

Section 4.1:
I'm curious about the "Sites MAY also define a maximum days value, which
MUST be greater than 7, and SHOULD be greater than 30" text.  Why use a MUST
for what appears to be an operational matter?  What is the impact on
interoperability if a lesser value is used?

Section 4.2:  "Implementations are free to limit the number of remembered
responses, provided the limit is no less than 1000."
Why 1000, and is this a normative requirement or not?

Section 4.7: "A script will fail if it attempts to execute two or more
vacation actions."
Should "will" be either SHOULD or MUST?  "will" describes an implementation
behavior.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KErmpB022150; Thu, 20 Oct 2005 07:53:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KErmW1022149; Thu, 20 Oct 2005 07:53:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KErlt4022141 for <[e-mail]>; Thu, 20 Oct 2005 07:53:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESbnd-0002Bg-Ro for [e-mail]; Thu, 20 Oct 2005 16:53:45 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESbnd-0001w8-Pd for [e-mail]; Thu, 20 Oct 2005 16:53:45 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESbnd-0006bS-EE for [e-mail]; Thu, 20 Oct 2005 16:53:45 +0200
Date: Thu, 20 Oct 2005 16:53:45 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

> >If I simply let notify understand SMS URIs with the parameter "route",
> >the URI will violate the officially specified URI definition.  Possible,
> >but almost correct just isn't.
> >
> One can write a new draft extending an existing URI scheme.

If I were to review such a draft, I would not accept it, unless the
scheme name or overall syntax changed.  Something like Exim's URIs
that begin with attribute-value pairs, separated by white space
and followed by the URI is fine.

If the editor of an URI scheme refuses to change it, or if the revision
process takes too long, I think that should be accepted and ways to pass
information not in, but next to the URI, should be chosen.

> >Change all concerned URI schemes?
> >
> So far we've identified only 3, I don't think it would be too hard. I 
> don't think anybody is proposing to examine all standardized URI types.

I have little to no experience in that area.  If you think changing xmpp
(sp?), sms and mailto could be changed, I am more than willing to forget
about tagged arguments mapped to URI parameters, attribute-value pairs
and the like.

Changing the mailto URI is troublesome, because it contains one namespace
for both headers and other parameters.  If someone introduced a new header
field called "Body", it would fail badly.  You can't specify credentials,
message transmission modes or even the smart host to use, and you can't
add any of that, because it would conflict with header names.  Up to
now, all I have trouble with are the security considerations and their
consequences.  Should that ever change and new parameters are required,
that route is a dead end.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KEXrbA020265; Thu, 20 Oct 2005 07:33:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KEXrme020264; Thu, 20 Oct 2005 07:33:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KEXqr0020258 for <[e-mail]>; Thu, 20 Oct 2005 07:33:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.182] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 20 Oct 2005 15:33:47 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Oct 2005 15:33:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>>>o  Extend existing URI with new invented parameters.  Quite a kludge.
>>>      
>>>
>>How is this different from the next?
>>    
>>
>
>If I simply let notify understand SMS URIs with the parameter "route",
>the URI will violate the officially specified URI definition.  Possible,
>but almost correct just isn't.
>  
>
One can write a new draft extending an existing URI scheme.

>>>o  Try to officially extend the URI schemes by parameters we need.  I
>>> don't know if that is possible.  Of course it would be very elegant.
>>>      
>>>
>>Sure, why not.
>>    
>>
>
>Change all concerned URI schemes?
>
So far we've identified only 3, I don't think it would be too hard. I 
don't think anybody is proposing to examine all standardized URI types.

>The keyword "ivory tower" was already
>mentioned.  I favour this approach, but working without a backup strategy
>sounds risky.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KESb8u019673; Thu, 20 Oct 2005 07:28:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KESbnn019672; Thu, 20 Oct 2005 07:28:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from chiark.greenend.org.uk ([e-mail] [193.201.200.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KESaqh019666 for <[e-mail]>; Thu, 20 Oct 2005 07:28:36 -0700 (PDT) (envelope-from [e-mail])
Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path [e-mail]) id 1ESbPG-00026Z-00 for [e-mail]; Thu, 20 Oct 2005 15:28:34 +0100
To: [e-mail]
From: Tony Finch <[e-mail]>
Subject: Re: List of issues with Sieve notifications
In-Reply-To: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 20 Oct 2005 15:28:34 +0100
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>

Michael Haardt <[e-mail]> wrote:
>
>Perhaps my suggestion of introducing ":from" was a bad idea and it should
>be dropped along with ":priority", adding something like ":attributes",
>that passes a string list of attribute-value pairs to the method,
>leaving it up to the method definition or even the implementation which
>attribute to process:
>
>  notify :attributes ["priority=low","from=sender@domain"] "mailto:0123456789@gateway";

The Cyrus notify implementation (based on an early draft) has :options.

Tony.
-- 
f.a.n.finch  <[e-mail]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHEAST 7 TO SEVERE GALE 9. RAIN. MODERATE OR
GOOD.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KENZpS019209; Thu, 20 Oct 2005 07:23:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KENZYd019208; Thu, 20 Oct 2005 07:23:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KENYnE019199 for <[e-mail]>; Thu, 20 Oct 2005 07:23:34 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESbKP-00089i-W1 for [e-mail]; Thu, 20 Oct 2005 16:23:33 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESbKP-00076Z-Th for [e-mail]; Thu, 20 Oct 2005 16:23:33 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESbKN-0006aL-Gp for [e-mail]; Thu, 20 Oct 2005 16:23:31 +0200
Date: Thu, 20 Oct 2005 16:23:31 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: status of 3028bis
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

> >Let "i;octet" work on characters and document the name is a misnomer.
> >
> >IF someone really feels the need to specify and implement them: Introduce
> >Sieve extensions for a "i;binary" comparator that compares against a
> >string representation of binary data.  Introduce new tests "rawheader"
> >and "decodedheader".
> >
> >I am not aware how "i;octet" is used at other places, so the above may
> >only fit well to Sieve.
> > 

> Your suggestion make sense for header fields. But what about body 
> extension when matching against application/* MIME part?

I don't think the MIME type should make a difference on what a test or
comparator does, or how the literal used for comparison is represented.
Things get too confusing otherwise.

That having said, using "i;octet" could not be used reasonably on decoded
MIME parts that can not be translated to unicode.  Trying to do so should
yield the same behaviour as it does on headers that can not be translated
to unicode, e.g. because their character set is not known.

The imaginary "i;binary" comparator would be the proper solution to
compare with an octet sequence, working on the decoded part, if we tried
to keep a minimum of logic.  And I really hope the extension does not
specify what exactly "i;octet" does to let me get away with saying: I am
not breaking it.

Honestly, I never looked at the body extension, because it is way
too expensive for my systems.  Skimming it, it does not talk about
comparators and assumes they work as defined by external references,
which is the way it should be.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KE6SUZ017837; Thu, 20 Oct 2005 07:06:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KE6SJh017836; Thu, 20 Oct 2005 07:06:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KE6RZu017827 for <[e-mail]>; Thu, 20 Oct 2005 07:06:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESb3r-0005OL-8v for [e-mail]; Thu, 20 Oct 2005 16:06:27 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESb3r-0007if-5X for [e-mail]; Thu, 20 Oct 2005 16:06:27 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESb3o-0006Zi-Nw for [e-mail]; Thu, 20 Oct 2005 16:06:24 +0200
Date: Thu, 20 Oct 2005 16:06:24 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 20, 2005 at 02:43:57PM +0100, Alexey Melnikov wrote:
> >draft-duerst-mailto-bis-00 (expired?) extends RFC 2368 and says:
> >
> >4.  Unsafe Headers
> >
> >   The user agent interpreting a mailto URI SHOULD choose not to create
> >   a message if any of the headers are considered dangerous; it may also
> >   choose to create a message with only a subset of the headers given in
> >   the URI.  Only the Subject, Keywords, and Body headers are believed
> >   to be both safe and useful.
> >
> >   The creator of a mailto URI cannot expect the resolver of a URI to
> >   understand more than the "subject" and "body" headers.
> >
> >Ok, again a draft, but successor of a RFC.  Obviously, "from" and
> >"x-priority" are not considered safe, yet we would like to use them.
> > 
> >
> Different application of URIs have different needs. We can amend this 
> requirement for Sieve WG documents.

I sent mail to the authors, but did not get an answer so far.  You hit
the point: The draft focuses on interactive applications working on URIs
from untrusted sources.  That scope is too narrow.

> >o  Invent new generic options that cover all methods and each method
> >  picks the options it understands and ignores the rest.  This extends
> >  URIs in an invisible way, but having the options in the notify spec
> >  is a problem if a new scheme needs more.  Putting them in the method
> >  specs sounds very bad to me.
> > 
> "option" is "tagged attribute", right?

Right.  I should have gotten used to say "tagged attribute" by now. :-/

> >o  Pass generic attribute-value pairs to methods, and each method
> >  picks the options it understands and ignores the rest.  This extends
> >  URIs in an invisible way, but does not engrave the option names
> >  in rock.
> > 
> If we do that, we should create a new IANA registry, which is going to 
> be the one true place to locate description of all notification options.

Good idea!

> One good thing about standardized attribute-value pairs is that they 
> might be more readable to people than an URI parameter.
> So if we have "priority=high", it might be representable in both mailto: 
> and XMPP (frankly I don't know that it is true to XMPP URI, but let's 
> assume for a moment that it is) URIs, but it will have different syntax 
> that script writers would need to know.

Each method spec must tell which URI parameters will be ignored anyway.
The mailto spec will say that the subject and body URI parameters
will be ignored, because notify will set these.  I had no problem on
further saying that the x-priority parameter will be ignored, because
its value is determine from the "priority" attribute-value pair.

And perhaps they should not be ignored, but cause an error if given.
I don't know yet, but that's a different issue.

> So effectively attribute-value pairs would extend and/or override URI 
> parameters.

Yes.

> >o  Invent new URI schemes.  Ugly as hell.
> >
> >o  Extend existing URI with new invented parameters.  Quite a kludge.
> >
> How is this different from the next?

If I simply let notify understand SMS URIs with the parameter "route",
the URI will violate the officially specified URI definition.  Possible,
but almost correct just isn't.

> >o  Try to officially extend the URI schemes by parameters we need.  I
> >  don't know if that is possible.  Of course it would be very elegant.
> >
> Sure, why not.

Change all concerned URI schemes? The keyword "ivory tower" was already
mentioned.  I favour this approach, but working without a backup strategy
sounds risky.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDxOc7016456; Thu, 20 Oct 2005 06:59:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KDxOvT016455; Thu, 20 Oct 2005 06:59:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDxNrT016442 for <[e-mail]>; Thu, 20 Oct 2005 06:59:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.182] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 20 Oct 2005 14:59:05 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Oct 2005 14:59:04 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: status of 3028bis
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Tue, Oct 18, 2005 at 02:06:00PM -0700, Philip Guenther wrote:
>  
>
>>In particular, there's some uncertainty
>>over whether comparators take octets or characters as input and how
>>i;octet is defined and used in the definition of other comparators.
>>    
>>
[...]

>Let "i;octet" work on characters and document the name is a misnomer.
>
>IF someone really feels the need to specify and implement them: Introduce
>Sieve extensions for a "i;binary" comparator that compares against a
>string representation of binary data.  Introduce new tests "rawheader"
>and "decodedheader".
>
>I am not aware how "i;octet" is used at other places, so the above may
>only fit well to Sieve.
>  
>
Your suggestion make sense for header fields. But what about body 
extension when matching against application/* MIME part?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDpaIW014244; Thu, 20 Oct 2005 06:51:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KDpaCh014243; Thu, 20 Oct 2005 06:51:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDpZ1K014233 for <[e-mail]>; Thu, 20 Oct 2005 06:51:36 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESapS-0001oM-9B for [e-mail]; Thu, 20 Oct 2005 15:51:34 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESapS-00080W-0b for [e-mail]; Thu, 20 Oct 2005 15:51:34 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESapO-0006Yz-Gy for [e-mail]; Thu, 20 Oct 2005 15:51:30 +0200
Date: Thu, 20 Oct 2005 15:51:30 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 19, 2005 at 05:19:03PM +0200, Kjetil Torgrim Homme wrote:
> On Wed, 2005-10-19 at 15:49 +0200, Michael Haardt wrote:
> > The user could have meant to use mailto, because he set a :from, but
> > then typed sms as method.  Or he could have meant sms, but typed from
> > by mistake.  That's the problem with overloading: You don't select
> > methods by name, but by signature, and if signatures don't match, you
> > have no idea what could have been meant.
> 
> you _do_ select the method by name.  don't try to be smart, use the
> scheme the user has named.  if the user makes a typo in the scheme name,
> that is no different from any other typo in a Sieve script.

Do you say that the :method option is more important than :from? I
can not justify that, but if we make the :method string mandatory,
things are different.

> > Putting all possible options in the notify spec, no matter if as syntactic
> > elements, or as generic attribute-value pairs, solves this problem:
> > The method decides which options to look at and other options are ignored.
> > That's a rule users can understand very well.
> 
> no, that's much more confusing.  silently ignoring, say, :from, is not
> helpful to the user who wonders why the sender address is wrong ("it
> worked with mailto!")

That's a different issue.  Options not used by a specific method could
be ignored or cause an error.  I tend to agree with you on this, and
if the method is indeed mandatory, the specification would be very easy
to understand.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDi6TQ013124; Thu, 20 Oct 2005 06:44:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KDi6wI013123; Thu, 20 Oct 2005 06:44:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KDi4np013116 for <[e-mail]>; Thu, 20 Oct 2005 06:44:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.182] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 20 Oct 2005 14:43:59 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Oct 2005 14:43:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Mon, Oct 17, 2005 at 01:52:04PM -0400, Mark E. Mallett wrote:
>  
>
>>I kind of like ":from" but it seems to me that something like
>>:attributes, to pass specific information to a particular notification
>>method, would be covered by the URI format for that method.  The
>>standardization of attribute names (if any) would be done at the URI
>>encoding level.  (If a URI has not been standardized for a specific
>>method, corresponding attribute names wouldn't have been, either.)
>>    
>>
>
>Do you suggest to invent new URI schemes?
>
>draft-wilde-sms-uri-10 does not allow to specify a sender or a specific
>route.  Sure, mobile phones don't allow that, but gateways do.  I realize
>it is a draft and could be changed.
>
>draft-duerst-mailto-bis-00 (expired?) extends RFC 2368 and says:
>
>4.  Unsafe Headers
>
>    The user agent interpreting a mailto URI SHOULD choose not to create
>    a message if any of the headers are considered dangerous; it may also
>    choose to create a message with only a subset of the headers given in
>    the URI.  Only the Subject, Keywords, and Body headers are believed
>    to be both safe and useful.
>
>    The creator of a mailto URI cannot expect the resolver of a URI to
>    understand more than the "subject" and "body" headers.
>
>Ok, again a draft, but successor of a RFC.  Obviously, "from" and
>"x-priority" are not considered safe, yet we would like to use them.
>  
>
Different application of URIs have different needs. We can amend this 
requirement for Sieve WG documents.

>Are we abusing URIs to perform something they were not made for, are
>we illustrating their schemes are lacking features or why else don't they
>fit?
>  
>
Just a general note than many URI types don't have many features 
supported by the protocol, two examples are HTTP and IMAP.
For example HTTP doesn't have a way to specify HTTP method, i.e. 
POST/GET/PUT/etc.

>I see a bunch possible approaches:
>
>o  Invent new generic options that cover all methods and each method
>   picks the options it understands and ignores the rest.  This extends
>   URIs in an invisible way, but having the options in the notify spec
>   is a problem if a new scheme needs more.  Putting them in the method
>   specs sounds very bad to me.
>  
>
"option" is "tagged attribute", right?

>o  Pass generic attribute-value pairs to methods, and each method
>   picks the options it understands and ignores the rest.  This extends
>   URIs in an invisible way, but does not engrave the option names
>   in rock.
>  
>
If we do that, we should create a new IANA registry, which is going to 
be the one true place to locate description of all notification options.

One good thing about standardized attribute-value pairs is that they 
might be more readable to people than an URI parameter.
So if we have "priority=high", it might be representable in both mailto: 
and XMPP (frankly I don't know that it is true to XMPP URI, but let's 
assume for a moment that it is) URIs, but it will have different syntax 
that script writers would need to know.

So effectively attribute-value pairs would extend and/or override URI 
parameters.

>o  Invent new URI schemes.  Ugly as hell.
>
>o  Extend existing URI with new invented parameters.  Quite a kludge.
>  
>
How is this different from the next?

>o  Try to officially extend the URI schemes by parameters we need.  I
>   don't know if that is possible.  Of course it would be very elegant.
>  
>
Sure, why not.

>As a matter of fact, we need to pass data that can't be passed through
>existing schemes.  I really only like the last, but doubt it is a
>solution.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KBZgus099496; Thu, 20 Oct 2005 04:35:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KBZgWV099495; Thu, 20 Oct 2005 04:35:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KBZfTU099485 for <[e-mail]>; Thu, 20 Oct 2005 04:35:42 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.182] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 20 Oct 2005 12:35:27 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Oct 2005 12:35:26 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Philip Guenther wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Philip Guenther wrote:
>>    
>>
>>>Alexey Melnikov <[e-mail]> writes:
>>>      
>>>
>>>>Philip Guenther wrote:
>>>>        
>>>>
>>>>>In section 1, I suggest changing
>>>>> Sieve interpreters that don't support integration with IMAP SHOULD
>>>>> ignore this extension.
>>>>>          
>>>>>
>...<discussion elided>...
>  
>
>>How about removing this sentence?
>>    
>>
>
>That works for me.
>  
>
Done in my copy.

>BTW, I suggest dropping "referenced by a variable" from the description
>of :flags in section 3, as the flag list used with :flags doesn't
>require variables.  Indeed,
>	keep :flags "";
>is useful as a way to ignore the internal flag list variable.
>  
>
I agree.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JHjdjA096024; Wed, 19 Oct 2005 10:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JHjd1Z096023; Wed, 19 Oct 2005 10:45:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JHjc6g096017 for <[e-mail]>; Wed, 19 Oct 2005 10:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 19 Oct 2005 18:45:34 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Oct 2005 18:45:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Editors: please update all your documents
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

All documents referencing RFC 2234 or 2234bis should be updated to 
reference RFC 4234 now.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JFJI3q076382; Wed, 19 Oct 2005 08:19:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JFJIan076381; Wed, 19 Oct 2005 08:19:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JFJHi2076369 for <[e-mail]>; Wed, 19 Oct 2005 08:19:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1ESFij-00070F-Sd; Wed, 19 Oct 2005 17:19:13 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ESFig-0008H9-Aw; Wed, 19 Oct 2005 17:19:10 +0200
Subject: Re: List of issues with Sieve notifications
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 19 Oct 2005 17:19:03 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.625, required 12, autolearn=disabled, AWL 1.19, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-19 at 15:49 +0200, Michael Haardt wrote:
> The user could have meant to use mailto, because he set a :from, but
> then typed sms as method.  Or he could have meant sms, but typed from
> by mistake.  That's the problem with overloading: You don't select
> methods by name, but by signature, and if signatures don't match, you
> have no idea what could have been meant.

you _do_ select the method by name.  don't try to be smart, use the
scheme the user has named.  if the user makes a typo in the scheme name,
that is no different from any other typo in a Sieve script.

> Putting all possible options in the notify spec, no matter if as syntactic
> elements, or as generic attribute-value pairs, solves this problem:
> The method decides which options to look at and other options are ignored.
> That's a rule users can understand very well.

no, that's much more confusing.  silently ignoring, say, :from, is not
helpful to the user who wonders why the sender address is wrong ("it
worked with mailto!")
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JEsWfb073459; Wed, 19 Oct 2005 07:54:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JEsWS8073458; Wed, 19 Oct 2005 07:54:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JEsV6Q073452 for <[e-mail]>; Wed, 19 Oct 2005 07:54:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESFKo-0001ss-G8 for [e-mail]; Wed, 19 Oct 2005 16:54:30 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1ESFKo-0004qB-Cw for [e-mail]; Wed, 19 Oct 2005 16:54:30 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESFKl-0005ka-1L for [e-mail]; Wed, 19 Oct 2005 16:54:27 +0200
Date: Wed, 19 Oct 2005 16:54:27 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

Section 5, Security Considerations, says:

    Security considerations are discussed in [SIEVE]. Additionally
    implementations must be careful to follow the security
    considerations of the specific notification methods. It is believed
    that this extension does not introduce any additional security
    concerns.

As it is, notify without a specified method uses a site-specific default
method.  That does introduce a security risk to notify itself, and the
default method may not follow any standard.  How about dropping :method
and require the URI to be a fixed parameter (first?) of notify?

    The notify action is potentially very dangerous.  The path the
    notification takes through the network may not be secure.

I suggest:

    The notify action is potentially very dangerous.  The path the
    notification takes through the network may not be secure, and
    if sent to a gateway, it may even leave the network and network
    security measures no longer apply.

Additionally, I would like to express that sending a notification is at
least as insecure as forwarding the mail causing it to the notification
recipient, but I am not sure if that goes too far.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JEXA4d067912; Wed, 19 Oct 2005 07:33:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JEXA5t067911; Wed, 19 Oct 2005 07:33:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JEX9ff067890 for <[e-mail]>; Wed, 19 Oct 2005 07:33:10 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESF08-0001B3-Ex for [e-mail]; Wed, 19 Oct 2005 16:33:08 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESF08-0000Ef-D6 for [e-mail]; Wed, 19 Oct 2005 16:33:08 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESF06-0005jZ-7f for [e-mail]; Wed, 19 Oct 2005 16:33:06 +0200
Date: Wed, 19 Oct 2005 16:33:06 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Mon, Oct 17, 2005 at 02:01:57PM +0100, Alexey Melnikov wrote:
> Maybe the document is not clear, but I am not suggesting silently 
> ignoring errors: an error message can be logged, but the script 
> execution should continue.

The base spec (section 2.6.10, at the end) requires that the user is
informed of errors, in which case the message is kept.  In case this means
there must be means by which Sieve can also send messages in absence of
errors, we really need to document that in the base spec.  Otherwise,
you can not rely on being able to generate warnings.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JDo0Rg043557; Wed, 19 Oct 2005 06:50:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JDo0UQ043555; Wed, 19 Oct 2005 06:50:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JDnxUA043537 for <[e-mail]>; Wed, 19 Oct 2005 06:49:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESEKL-0003oY-LF for [e-mail]; Wed, 19 Oct 2005 15:49:57 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESEKL-0006PC-K9 for [e-mail]; Wed, 19 Oct 2005 15:49:57 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESEKL-0005gD-Ar for [e-mail]; Wed, 19 Oct 2005 15:49:57 +0200
Date: Wed, 19 Oct 2005 15:49:57 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 19, 2005 at 03:28:49PM +0200, Kjetil Torgrim Homme wrote:
> > Say you have two methods:
> > 
> > "sms", which offers the option "route" to specify the route
> > "mailto", which offers the option "from" to specify the sender
> > 
> > What's the error message on:
> > 
> >   notify :from "[e-mail]" :method "sms:0123456789" ;
> > 
> > It is: No matching option signature.  Now that's an error users are
> > really going to hate.
> 
> no, the argument to :method is a structured value, so we can trivially
> know that if :method "foo:whatever" exists without a require
> "notify-foo", it's an error.  this is similar to the requirements for
> comparator.

As I said, insisting on require or not is independent of this issue.
In the example above, assume I requested both the sms and the mailto URI
scheme for notify.  I am not talking about pro or con of using require
to request specific methods, but about why putting syntactic elements
in the method specs is bad:

Looking at the example, the option signature consists of one option only
found in mailto, and the method option found in notify, but with a value
that indicates the sms method should be used.

The user could have meant to use mailto, because he set a :from, but
then typed sms as method.  Or he could have meant sms, but typed from
by mistake.  That's the problem with overloading: You don't select
methods by name, but by signature, and if signatures don't match, you
have no idea what could have been meant.

Putting all possible options in the notify spec, no matter if as syntactic
elements, or as generic attribute-value pairs, solves this problem:
The method decides which options to look at and other options are ignored.
That's a rule users can understand very well.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JDTIAp033509; Wed, 19 Oct 2005 06:29:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JDTIUX033508; Wed, 19 Oct 2005 06:29:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JDTHUm033498 for <[e-mail]>; Wed, 19 Oct 2005 06:29:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1ESE0E-0005Df-Di; Wed, 19 Oct 2005 15:29:10 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ESE00-0005D4-Dv; Wed, 19 Oct 2005 15:28:56 +0200
Subject: Re: List of issues with Sieve notifications
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 19 Oct 2005 15:28:49 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.67, required 12, autolearn=disabled, AWL 1.14, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-19 at 13:21 +0200, Michael Haardt wrote:
> On Tue, Oct 18, 2005 at 11:15:53PM +0200, Kjetil Torgrim Homme wrote:
> > why is putting them in the method spec bad?  adding syntax elements does
> > mean we need an extension for each method, e.g., require "notify-sms",
> > but I don't think that is a bad thing at all.  it means the user will
> > have a way of knowing which notification methods are supported,
> > something he can't do today.
> 
> Putting options in the method spec is bad, because basically it
> introduces overloading.  Suddenly, a parser could not detect
> errors on unknown options when parsing the notify arguments, but
> first must parse all options, and then semantic analysis has to
> find out if there is a signature for them.
> 
> Say you have two methods:
> 
> "sms", which offers the option "route" to specify the route
> "mailto", which offers the option "from" to specify the sender
> 
> What's the error message on:
> 
>   notify :from "[e-mail]" :method "sms:0123456789" ;
> 
> It is: No matching option signature.  Now that's an error users are
> really going to hate.

no, the argument to :method is a structured value, so we can trivially
know that if :method "foo:whatever" exists without a require
"notify-foo", it's an error.  this is similar to the requirements for
comparator.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JBLSi7021214; Wed, 19 Oct 2005 04:21:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JBLSqD021213; Wed, 19 Oct 2005 04:21:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JBLQ9C021207 for <[e-mail]>; Wed, 19 Oct 2005 04:21:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESC0c-00030g-GM for [e-mail]; Wed, 19 Oct 2005 13:21:26 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1ESC0c-0004Zm-D6 for [e-mail]; Wed, 19 Oct 2005 13:21:26 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESC0b-0005Xk-2O for [e-mail]; Wed, 19 Oct 2005 13:21:25 +0200
Date: Wed, 19 Oct 2005 13:21:25 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Tue, Oct 18, 2005 at 11:15:53PM +0200, Kjetil Torgrim Homme wrote:
> > o  Invent new generic options that cover all methods and each method
> >    picks the options it understands and ignores the rest.  This extends
> >    URIs in an invisible way, but having the options in the notify spec
> >    is a problem if a new scheme needs more.  Putting them in the method
> >    specs sounds very bad to me.
> 
> why is putting them in the method spec bad?  adding syntax elements does
> mean we need an extension for each method, e.g., require "notify-sms",
> but I don't think that is a bad thing at all.  it means the user will
> have a way of knowing which notification methods are supported,
> something he can't do today.

Putting options in the method spec is bad, because basically it
introduces overloading.  Suddenly, a parser could not detect
errors on unknown options when parsing the notify arguments, but
first must parse all options, and then semantic analysis has to
find out if there is a signature for them.

Say you have two methods:

"sms", which offers the option "route" to specify the route
"mailto", which offers the option "from" to specify the sender

What's the error message on:

  notify :from "[e-mail]" :method "sms:0123456789" ;

It is: No matching option signature.  Now that's an error users are
really going to hate.

Right now, the only Sieve extension introducing something similar is
"copy".  To me, it looks like nobody thought about what an extension like
that really means, but since it is the only one, everything is fine.
Is it overloading or just an extension? Say I invent a new extension
that introduces another option for fileinto.  If extensions overloaded
the option signature, I couldn't mix it with "copy".  If I could, then
it must not modify the implicit keep flag.  Oops.

The sieve specification contains a small grammar, expressed formally,
and a large semantic part, expressed in natural language.  IMHO, the
latter is the weak part, because it leaves too much freedom.  Please,
let's not open this can of worms.

All this is independent of having to request methods by a Sieve
extensions or not.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JAn26s017632; Wed, 19 Oct 2005 03:49:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JAn28t017631; Wed, 19 Oct 2005 03:49:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JAn0J2017622 for <[e-mail]>; Wed, 19 Oct 2005 03:49:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ESBVD-0003qq-EQ for [e-mail]; Wed, 19 Oct 2005 12:48:59 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ESBVD-0007wS-AM for [e-mail]; Wed, 19 Oct 2005 12:48:59 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #10) id 1ESBVC-0005Wl-WB for [e-mail]; Wed, 19 Oct 2005 12:48:59 +0200
Date: Wed, 19 Oct 2005 12:48:58 +0200
From: Michael Haardt <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Re: status of 3028bis
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Tue, Oct 18, 2005 at 02:06:00PM -0700, Philip Guenther wrote:
> In particular, there's some uncertainty
> over whether comparators take octets or characters as input and how
> i;octet is defined and used in the definition of other comparators.

We had that discussion before and you summarised it very well.  I
agree with it, but want to add reasons:

Summary:

In Sieve, comparators act on characters, not octets.  Looking only at the
base specification, "i;octet" is badly named and means: "Compare unicode
character by unicode character".  At least I think that's what we agreed
on and why the text said UTF-8 before, and unicode now.  The change from
UTF-8 to unicode was made, because although Sieve is written in UTF-8,
implementations should not be forced to work in UTF-8 inside, but use
whatever unicode encoding they like.

Reason:

Indeed, we lack the other two levels: There is no way to work on raw
headers, but at least we agreed that if we want to do that, we would
invent a new test like "rawheader".  And there is no way to work on
the MIME decoded data without character set conversion to unicode.
We have no access to the MIME character set specification, either.

If "i;octet" were to match arbitrary binary data, thus omitting the
character set translation, it would be mostly useless, as there are
ISO-8859-15 strings that are invalid UTF-8 strings and Sieve scripts
are expressed in UTF-8.  Sieve offers no binary data literals.  It is
bad enough that the decoded header data may contain NUL characters and
Sieve can not express those (\0 does not have a special meaning), but at
least we can match any unicode character else.  Since headers contain
only characters of a specific character set, and rarely just random
binary data, it makes sense "i;octet" does indeed work on decoded and
translated characters, despite its name.

If it were for me, I would: Introduce a new comparator instead,
e.g. "i;character", and change "i;octet" to match against a string
representation of binary data, e.g. hex characters.  And introduce
\0 to mean NUL at the same time. :-)

But Sieve is widespread by now and that would break many scripts.
Not even I dare to suggest going that way.  That's why I suggest:

Let "i;octet" work on characters and document the name is a misnomer.

IF someone really feels the need to specify and implement them: Introduce
Sieve extensions for a "i;binary" comparator that compares against a
string representation of binary data.  Introduce new tests "rawheader"
and "decodedheader".

I am not aware how "i;octet" is used at other places, so the above may
only fit well to Sieve.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ILGibN024278; Tue, 18 Oct 2005 14:16:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ILGilH024277; Tue, 18 Oct 2005 14:16:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ILGhT2024271 for <[e-mail]>; Tue, 18 Oct 2005 14:16:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1ERyp6-0001iq-2y; Tue, 18 Oct 2005 23:16:40 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ERyob-0005iZ-SW; Tue, 18 Oct 2005 23:16:09 +0200
Subject: Re: List of issues with Sieve notifications
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 18 Oct 2005 23:15:53 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.459, required 12, autolearn=disabled, AWL 1.35, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Mon, 2005-10-17 at 21:00 +0200, Michael Haardt wrote:
> I see a bunch possible approaches:
> 
> o  Invent new generic options that cover all methods and each method
>    picks the options it understands and ignores the rest.  This extends
>    URIs in an invisible way, but having the options in the notify spec
>    is a problem if a new scheme needs more.  Putting them in the method
>    specs sounds very bad to me.

why is putting them in the method spec bad?  adding syntax elements does
mean we need an extension for each method, e.g., require "notify-sms",
but I don't think that is a bad thing at all.  it means the user will
have a way of knowing which notification methods are supported,
something he can't do today.

this would also solve item 1 on Alexey's list ("Need to change the
extension name") :-)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IL61Ad023086; Tue, 18 Oct 2005 14:06:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IL61Ub023085; Tue, 18 Oct 2005 14:06:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IL61jq023079 for <[e-mail]>; Tue, 18 Oct 2005 14:06:01 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9IL60u7029664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 18 Oct 2005 14:06:00 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j9IL60u7029664
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=ORCw7itMmk/NAdLlC4oWn8/2sMEIIiTUZvvn1aVRCOfHrCfcfMK3clF13OwYqr4F4 qmrVqDmu5SOTNpOMjspVpwNyXZjlke0cPzrAE9KMhMlLeYo5PA47fwZ1u91PNau0aUI EkqPjTK5oVjBtuc0qc+s+G6Psa/t1Mv7iZ6SIcg=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j9IL60iK033990 for <[e-mail]>; Tue, 18 Oct 2005 14:06:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: status of 3028bis
Date: Tue, 18 Oct 2005 14:06:00 -0700
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>

For those wondering what's up with the Sieve base spec, it's currently
held up waiting for the comparator draft (draft-newman-i18n-comparator-04)
to get nailed down a bit.  In particular, there's some uncertainty
over whether comparators take octets or characters as input and how
i;octet is defined and used in the definition of other comparators.
THe resolution of those issues are likely to require changes to
3028bis, so it would *really* help if more people reviewed the draft
and the discussion thereof.

The comparator draft is discussed on <[e-mail]>,
which is archived at
	http://lists.w3.org/Archives/Public/public-ietf-collation/


This draft is a direct dependency of 3028bis, the IMAP i18n draft
(draft-ietf-imapext-i18n-05), and is also holding up the completion
of the Sieve 'body' extension, so we should all be interested in
finishing it.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IKVY73020129; Tue, 18 Oct 2005 13:31:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IKVY4l020128; Tue, 18 Oct 2005 13:31:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IKVY3g020120 for <[e-mail]>; Tue, 18 Oct 2005 13:31:34 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9IKVTu7021112 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 18 Oct 2005 13:31:29 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j9IKVTu7021112
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=PBT3FCG2hpMVBAHD70aAX2zamU/tVWhcU5m8MUhkoNFveHJw5+2tSDYnOqy9LbsC+ hnFvvq6gg0UF+qwXnnQ2sDEV1fn5qgKcOj/Jtafao9nm2NxDNmBgK/grVzHAnIu+ei/ 7U814N9QSqa2unO4hV/T0uFtRZtytojFEknm5Fs=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j9IKVSNI031271; Tue, 18 Oct 2005 13:31:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
From: Philip Guenther <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 18 Oct 2005 13:31:28 -0700
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>

Alexey Melnikov <[e-mail]> writes:
>Philip Guenther wrote:
>>Alexey Melnikov <[e-mail]> writes:
>>>Philip Guenther wrote:
>>>
>>>>In section 1, I suggest changing
>>>>  Sieve interpreters that don't support integration with IMAP SHOULD
>>>>  ignore this extension.
...<discussion elided>...
>How about removing this sentence?

That works for me.


BTW, I suggest dropping "referenced by a variable" from the description
of :flags in section 3, as the flag list used with :flags doesn't
require variables.  Indeed,
	keep :flags "";
is useful as a way to ignore the internal flag list variable.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo3Ve016465; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IJo3mP016462; Tue, 18 Oct 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo2ij016439 for <[e-mail]>; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTG-0001bp-M0; Tue, 18 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-07.txt 
Message-Id: <[e-mail]>
Date: Tue, 18 Oct 2005 15:50:02 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-07.txt
	Pages		: 16
	Date		: 2005-10-18
	
In advanced mail filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension to the filtering
   language Sieve changes the interpretation of strings, adds an action
   to store data in variables, and supplies a new test so that the value
   of a string can be examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-sieve-variables-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo3LD016455; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IJo325016453; Tue, 18 Oct 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo2hB016436 for <[e-mail]>; Tue, 18 Oct 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTF-0001Zo-Uo; Tue, 18 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-notify-01.txt 
Message-Id: <[e-mail]>
Date: Tue, 18 Oct 2005 15:50:01 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve -- An extension for providing instant notifications
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-notify-01.txt
	Pages		: 0
	Date		: 2005-10-18
	
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but is expected that using existing instant messaging
infrastructure such as Zephyr, Jabber, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific rules for how and when
notifications should be sent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-sieve-notify-01.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-notify-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo3lW016456; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IJo3x4016454; Tue, 18 Oct 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo2N9016435 for <[e-mail]>; Tue, 18 Oct 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTF-0001Zj-Tr; Tue, 18 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-02.txt 
Message-Id: <[e-mail]>
Date: Tue, 18 Oct 2005 15:50:01 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-02.txt
	Pages		: 0
	Date		: 2005-10-18
	
Recent discussions have shown that it is desirable to set different
   [IMAP] flags on message delivery.  This can be done, for example,
   by a Sieve interpreter that works as a part of a Mail Delivery
   Agent.

   This document describes an extension to the Sieve mail filtering
   language for setting [IMAP] flags. The extension allows to set both
   [IMAP] system flags and [IMAP] keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-sieve-imapflags-02.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-imapflags-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-imapflags-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo3ei016473; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IJo3ua016471; Tue, 18 Oct 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9IJo2iW016440 for <[e-mail]>; Tue, 18 Oct 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTG-0001bt-Mt; Tue, 18 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-03.txt 
Message-Id: <[e-mail]>
Date: Tue, 18 Oct 2005 15:50:02 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-03.txt
	Pages		: 0
	Date		: 2005-10-18
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-sieve-editheader-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ICYnrs071200; Tue, 18 Oct 2005 05:34:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ICYnLE071198; Tue, 18 Oct 2005 05:34:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ICYmWa071176 for <[e-mail]>; Tue, 18 Oct 2005 05:34:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Tue, 18 Oct 2005 13:34:39 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Oct 2005 10:35:07 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
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>

Philip Guenther wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Philip Guenther wrote:
>>    
>>
>>>In section 1, I suggest changing
>>>  Sieve interpreters that don't support integration with IMAP SHOULD
>>>  ignore this extension.
>>>to
>>>  This extension is only appropriate for sieve interpreters that
>>>  support integration with IMAP.
>>>(What does it mean for an interpreter to 'ignore' an extension?)
>>>      
>>>
>>I still the original sentence is better. Below are some examples that
>>explain the motivation for this sentence:
>>    
>>
>...
>
>Even with the examples, I still can't be sure what you mean by
>"ignore".
>
>Should the implementation "ignore the extension" by not supporting it,
>returning error if it's used with 'require'?  (This is what I originally
>thought you meant and was the goal of my suggested rewording.)
>
>Should it make its appearance in a 'require' a no-op, causing an error
>later if any of the *flag actions or test are actually used?
>
>Should it make the 'addflag' and 'removeflag' actions no-ops and the
>'hasflag' test always return false?
>
>Should it support the *flag actions and test completely and ignore only
>the effect on the 'keep' and 'fileinto' actions?
>
>
>I now _suspect_ the last is what you mean,
>
Yes.

> in which case the extension
>should perhaps be called the "atomset" extension, as all you're certain
>of getting when you require it is the ability to manipulate sets of
>atoms.  (Okay, I'm being slightly facetious there, but only slightly.)
>  
>
How about removing this sentence?
Section 5 already talks about ignoring flags that can't be stored, as 
well as saying:

   This document doesn't dictate how the Sieve interpreter will set
   the [IMAP] flags. In particular, the Sieve interpreter may work as
   an IMAP client, or may have direct access to the mailstore.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HJq2NH063780; Mon, 17 Oct 2005 12:52:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HJq2Ga063779; Mon, 17 Oct 2005 12:52:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9HJq1wR063765 for <[e-mail]>; Mon, 17 Oct 2005 12:52:01 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 37514 invoked by uid 101); 17 Oct 2005 15:52:00 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 17 Oct 2005 15:52:00 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Mon, Oct 17, 2005 at 09:00:37PM +0200, Michael Haardt wrote:
> On Mon, Oct 17, 2005 at 01:52:04PM -0400, Mark E. Mallett wrote:
> > I kind of like ":from" but it seems to me that something like
> > :attributes, to pass specific information to a particular notification
> > method, would be covered by the URI format for that method.  The
> > standardization of attribute names (if any) would be done at the URI
> > encoding level.  (If a URI has not been standardized for a specific
> > method, corresponding attribute names wouldn't have been, either.)
> 
> Do you suggest to invent new URI schemes?
> 
> draft-wilde-sms-uri-10 does not allow to specify a sender or a specific
> route.  Sure, mobile phones don't allow that, but gateways do.  I realize
> it is a draft and could be changed.

In fact I re-read that draft before making the comments above :-)


> Are we abusing URIs to perform something they were not made for, are
> we illustrating their schemes are lacking features or why else don't they
> fit?

My thinking was that if you need to convey some parameters to a
notification system, the things that you might want to convey ought to
be able to be specified in a URI for the method used by that system.
You've illustrated why that's an ivory-tower kind of approach, though.


> I see a bunch possible approaches:
> 
> o  Invent new generic options that cover all methods and each method
>    picks the options it understands and ignores the rest.  This extends
>    URIs in an invisible way, but having the options in the notify spec
>    is a problem if a new scheme needs more.  Putting them in the method
>    specs sounds very bad to me.
> 
> o  Pass generic attribute-value pairs to methods, and each method
>    picks the options it understands and ignores the rest.  This extends
>    URIs in an invisible way, but does not engrave the option names
>    in rock.
> 
> o  Invent new URI schemes.  Ugly as hell.
> 
> o  Extend existing URI with new invented parameters.  Quite a kludge.
> 
> o  Try to officially extend the URI schemes by parameters we need.  I
>    don't know if that is possible.  Of course it would be very elegant.
> 
> As a matter of fact, we need to pass data that can't be passed through
> existing schemes.  I really only like the last, but doubt it is a
> solution.

So the dilemma is that even if the URI ought to be the place to put
parameters (which I am inclined to think it is), we can't just go making
up non-standard URI elements.  (I am not in favor of inventing new
unofficial schemes or parameters either.)  Your :attributes idea is an
interesting technique to amend URIs in ways that have yet to be
standardized or even yet thought of, but one problem is that it can
become a free-for-all, with each implementation inventing its own
attribute names, and having to maintain support for them forever.  As
Alexey said, "now we have to standardize attribute names" to lessen the
impact of that.  And then at some point when some parameter makes its way
into a standardized URI syntax, more confusion will ensue.  (Of course
your #1 item has these problems too.)

The #1 and #2 items in your list are functionally equivalent, except
that #1 requires an RFC cycle to extend the tagged option set, whereas
#2 only requires a keyword registration (assuming that it's agreed that
registration is a good idea).  So :attributes is looking better to me
from that point of view.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HJ0oGD057280; Mon, 17 Oct 2005 12:00:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HJ0oME057279; Mon, 17 Oct 2005 12:00:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HJ0mAf057271 for <[e-mail]>; Mon, 17 Oct 2005 12:00:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ERaE0-0002Vp-J8 for [e-mail]; Mon, 17 Oct 2005 21:00:44 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ERaE0-0008Cs-Fa for [e-mail]; Mon, 17 Oct 2005 21:00:44 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #8) id 1ERaDt-0002cF-9p for [e-mail]; Mon, 17 Oct 2005 21:00:37 +0200
Date: Mon, 17 Oct 2005 21:00:37 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Mon, Oct 17, 2005 at 01:52:04PM -0400, Mark E. Mallett wrote:
> I kind of like ":from" but it seems to me that something like
> :attributes, to pass specific information to a particular notification
> method, would be covered by the URI format for that method.  The
> standardization of attribute names (if any) would be done at the URI
> encoding level.  (If a URI has not been standardized for a specific
> method, corresponding attribute names wouldn't have been, either.)

Do you suggest to invent new URI schemes?

draft-wilde-sms-uri-10 does not allow to specify a sender or a specific
route.  Sure, mobile phones don't allow that, but gateways do.  I realize
it is a draft and could be changed.

draft-duerst-mailto-bis-00 (expired?) extends RFC 2368 and says:

4.  Unsafe Headers

    The user agent interpreting a mailto URI SHOULD choose not to create
    a message if any of the headers are considered dangerous; it may also
    choose to create a message with only a subset of the headers given in
    the URI.  Only the Subject, Keywords, and Body headers are believed
    to be both safe and useful.

    The creator of a mailto URI cannot expect the resolver of a URI to
    understand more than the "subject" and "body" headers.

Ok, again a draft, but successor of a RFC.  Obviously, "from" and
"x-priority" are not considered safe, yet we would like to use them.

Are we abusing URIs to perform something they were not made for, are
we illustrating their schemes are lacking features or why else don't they
fit?

I see a bunch possible approaches:

o  Invent new generic options that cover all methods and each method
   picks the options it understands and ignores the rest.  This extends
   URIs in an invisible way, but having the options in the notify spec
   is a problem if a new scheme needs more.  Putting them in the method
   specs sounds very bad to me.

o  Pass generic attribute-value pairs to methods, and each method
   picks the options it understands and ignores the rest.  This extends
   URIs in an invisible way, but does not engrave the option names
   in rock.

o  Invent new URI schemes.  Ugly as hell.

o  Extend existing URI with new invented parameters.  Quite a kludge.

o  Try to officially extend the URI schemes by parameters we need.  I
   don't know if that is possible.  Of course it would be very elegant.

As a matter of fact, we need to pass data that can't be passed through
existing schemes.  I really only like the last, but doubt it is a
solution.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HHq7LE049625; Mon, 17 Oct 2005 10:52:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HHq7BA049622; Mon, 17 Oct 2005 10:52:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9HHq41E049572 for <[e-mail]>; Mon, 17 Oct 2005 10:52:05 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 91332 invoked by uid 101); 17 Oct 2005 13:52:04 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 17 Oct 2005 13:52:04 -0400
To: Alexey Melnikov <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Mon, Oct 17, 2005 at 04:18:45PM +0100, Alexey Melnikov wrote:
> Michael Haardt wrote:
> >Perhaps my suggestion of introducing ":from" was a bad idea and it should
> >be dropped along with ":priority", adding something like ":attributes",
> >that passes a string list of attribute-value pairs to the method,
> >leaving it up to the method definition or even the implementation which
> >attribute to process:
> >
> > notify :attributes ["priority=low","from=sender@domain"] 
> > "mailto:0123456789@gateway";
> > 
> >
> > notify :attributes ["route=immediate","from=0123456789"] "sms:0123456789" 
> > ;
> > 
> >
> This doesn't make things better, because now we need to standardize 
> attribute names.

I kind of like ":from" but it seems to me that something like
:attributes, to pass specific information to a particular notification
method, would be covered by the URI format for that method.  The
standardization of attribute names (if any) would be done at the URI
encoding level.  (If a URI has not been standardized for a specific
method, corresponding attribute names wouldn't have been, either.)

I guess an implementation would still be responsible for validating
the elements of a URI, e.g. if standard attribute names are enforced.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HFIsQU033139; Mon, 17 Oct 2005 08:18:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HFIsMq033138; Mon, 17 Oct 2005 08:18:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HFIqF8033132 for <[e-mail]>; Mon, 17 Oct 2005 08:18:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.156] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 17 Oct 2005 16:18:46 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Oct 2005 16:18:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Mon, Oct 17, 2005 at 01:54:51PM +0100, Alexey Melnikov wrote:
>  
>
>>>[priority]
>>>in which case the content of this field is very dependant on which 
>>>notification mechanism that is in use.
>>>      
>>>
>>Actually not, the content should be mapped to values expected by the 
>>notification mechanism.
>>    
>>
>
>Will we be able to find a single priority value that can be mapped to
>all methods and does that suffice? If so, great, but I doubt it.
>
>Exim uses URIs in some places and has the same problem of requiring
>additional parameters that are not part of the URI, e.g. authenticated
>and timeout parameters for LDAP URIs.  Its solution is to use strings
>like:
>
>  "attribute1=value1 attribute2=value2 URI"
>
>Perhaps my suggestion of introducing ":from" was a bad idea and it should
>be dropped along with ":priority", adding something like ":attributes",
>that passes a string list of attribute-value pairs to the method,
>leaving it up to the method definition or even the implementation which
>attribute to process:
>
>  notify :attributes ["priority=low","from=sender@domain"] "mailto:0123456789@gateway";
>  
>
>  notify :attributes ["route=immediate","from=0123456789"] "sms:0123456789" ;
>  
>
This doesn't make things better, because now we need to standardize 
attribute names.

I would like to have parameters for things that make sense in general. 
Note that this doesn't mean that every notification mechanism must 
support all of them. A notification mechanism can disregard some 
parameters, as long as it is clearly documented.

>The priority attribute may indeed set X-Priority, and even be specified
>as such, but I don't see how to map it to SMS.  The gateways I know
>offer different routes with names depending on the providers, offering
>different service qualities.
>
>Just a suggestion.  So far, I am not real happy either way.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HDqdCR022923; Mon, 17 Oct 2005 06:52:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HDqcDX022922; Mon, 17 Oct 2005 06:52:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HDqbfT022915 for <[e-mail]>; Mon, 17 Oct 2005 06:52:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ERVPo-0004dI-JK for [e-mail]; Mon, 17 Oct 2005 15:52:36 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1ERVPo-0000is-EJ for [e-mail]; Mon, 17 Oct 2005 15:52:36 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.54 #8) id 1ERVPm-0002W3-4s for [e-mail]; Mon, 17 Oct 2005 15:52:34 +0200
Date: Mon, 17 Oct 2005 15:52:34 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: List of issues with Sieve notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Mon, Oct 17, 2005 at 01:54:51PM +0100, Alexey Melnikov wrote:
> >[priority]
> >in which case the content of this field is very dependant on which 
> >notification mechanism that is in use.
> 
> Actually not, the content should be mapped to values expected by the 
> notification mechanism.

Will we be able to find a single priority value that can be mapped to
all methods and does that suffice? If so, great, but I doubt it.

Exim uses URIs in some places and has the same problem of requiring
additional parameters that are not part of the URI, e.g. authenticated
and timeout parameters for LDAP URIs.  Its solution is to use strings
like:

  "attribute1=value1 attribute2=value2 URI"

Perhaps my suggestion of introducing ":from" was a bad idea and it should
be dropped along with ":priority", adding something like ":attributes",
that passes a string list of attribute-value pairs to the method,
leaving it up to the method definition or even the implementation which
attribute to process:

  notify :attributes ["priority=low","from=sender@domain"] "mailto:0123456789@gateway";

  notify :attributes ["route=immediate","from=0123456789"] "sms:0123456789" ;

The priority attribute may indeed set X-Priority, and even be specified
as such, but I don't see how to map it to SMS.  The gateways I know
offer different routes with names depending on the providers, offering
different service qualities.

Just a suggestion.  So far, I am not real happy either way.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HD27dW017003; Mon, 17 Oct 2005 06:02:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HD27v8017002; Mon, 17 Oct 2005 06:02:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HD25kX016989 for <[e-mail]>; Mon, 17 Oct 2005 06:02:06 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 17 Oct 2005 14:01:59 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Oct 2005 14:01:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Sat, Oct 15, 2005 at 06:07:43PM +0100, Alexey Melnikov wrote:
>  
>
>>The case I had in mind is as follows: The notification URI is stored 
>>elsewhere (as an LDAP attribute or an IMAP annotation) and Sieve scripts 
>>uses Sieve variables extension to specify the notification method. Is it 
>>desirable for an unrecognized notification method to cause runtime 
>>error? I am open to suggestions.
>>    
>>
>
>People who use notifications usually consider some (or all) mails very
>important.  Silently ignoring errors,
>
Maybe the document is not clear, but I am not suggesting silently 
ignoring errors: an error message can be logged, but the script 
execution should continue.

>in particular when variables are
>involved and the error only happens every now and then, will make them
>think notifications were sent when they were not.  SMS are not reliable
>and they may complain about the service.
>
>If I specified some attribute of a message wrong and the message arrives,
>I will see what's up.  An error might have been better, but then again,
>I may be happy something worked at all.
>
>If I make a mistake and nothing is sent, but I don't get an error either,
>I am lost.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HCtm5n016173; Mon, 17 Oct 2005 05:55:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HCtmwe016172; Mon, 17 Oct 2005 05:55:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HCtl83016165 for <[e-mail]>; Mon, 17 Oct 2005 05:55:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 17 Oct 2005 13:54:52 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Oct 2005 13:54:51 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Nigel Swinson <[e-mail]>
CC: [e-mail]
Subject: Re: List of issues with Sieve notifications
References: <[e-mail]> <005001c5d30d$79651370$[e-mail]>
In-Reply-To: <005001c5d30d$79651370$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Nigel Swinson wrote:

>> 3). Changed priority into a string containing number (currently "1", 
>> "2" and "3") (Nigel)
>
> :o)
>
>> Would people prefer to use "high"/"normal"/"low" instead? I though 
>> that we might want to use relational on the priority, thus it is a 
>> number for now.
>
> I was thinking a number which can be followed by a description.  Then 
> you can use i;ascii-numeric comparator to ignore the text if you want 
> to use the :value match type.  ie "1 Low", "2", "3 Medium", "8 Uber 
> High" etc.
>
> Which now makes me think we drop it entirely leaving this feature to 
> the variables extension, however I guess the reason we have it is not 
> for filtering in the Sieve domain, but rather to pass to the 
> notification mechanism,

Yes.

> in which case the content of this field is very dependant on which 
> notification mechanism that is in use.

Actually not, the content should be mapped to values expected by the 
notification mechanism.

>   Perhaps we could use mailto: as an example and show this field in 
> use to set the x-priority header?

Sure.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HBPXVU006848; Mon, 17 Oct 2005 04:25:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HBPXPN006847; Mon, 17 Oct 2005 04:25:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HBPWu4006839 for <[e-mail]>; Mon, 17 Oct 2005 04:25:33 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.29) with ESMTP id <[e-mail]>; Mon, 17 Oct 2005 04:25:27 -0700
Message-ID: <005001c5d30d$79651370$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: List of issues with Sieve notifications
Date: Mon, 17 Oct 2005 12:25:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

> 3). Changed priority into a string containing number (currently "1", "2" 
> and "3") (Nigel)

:o)

> Would people prefer to use "high"/"normal"/"low" instead? I though that we 
> might want to use relational on the priority, thus it is a number for now.

I was thinking a number which can be followed by a description.  Then you 
can use i;ascii-numeric comparator to ignore the text if you want to use the 
:value match type.  ie "1 Low", "2", "3 Medium", "8 Uber High" etc.

Which now makes me think we drop it entirely leaving this feature to the 
variables extension, however I guess the reason we have it is not for 
filtering in the Sieve domain, but rather to pass to the notification 
mechanism, in which case the content of this field is very dependant on 
which notification mechanism that is in use.  Perhaps we could use mailto: 
as an example and show this field in use to set the x-priority header?

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9H850LA072214; Mon, 17 Oct 2005 01:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9H850US072213; Mon, 17 Oct 2005 01:05:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9H84xkv072202 for <[e-mail]>; Mon, 17 Oct 2005 01:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ERPzO-0003gc-Bj for [e-mail]; Mon, 17 Oct 2005 10:04:58 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ERPzO-00087Y-9U for [e-mail]; Mon, 17 Oct 2005 10:04:58 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1ERPzM-0001QN-Ub for [e-mail]; Mon, 17 Oct 2005 10:04:56 +0200
Date: Mon, 17 Oct 2005 10:04:56 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Sat, Oct 15, 2005 at 06:07:43PM +0100, Alexey Melnikov wrote:
> The case I had in mind is as follows: The notification URI is stored 
> elsewhere (as an LDAP attribute or an IMAP annotation) and Sieve scripts 
> uses Sieve variables extension to specify the notification method. Is it 
> desirable for an unrecognized notification method to cause runtime 
> error? I am open to suggestions.

People who use notifications usually consider some (or all) mails very
important.  Silently ignoring errors, in particular when variables are
involved and the error only happens every now and then, will make them
think notifications were sent when they were not.  SMS are not reliable
and they may complain about the service.

If I specified some attribute of a message wrong and the message arrives,
I will see what's up.  An error might have been better, but then again,
I may be happy something worked at all.

If I make a mistake and nothing is sent, but I don't get an error either,
I am lost.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9H2sQmm033157; Sun, 16 Oct 2005 19:54:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9H2sQSv033156; Sun, 16 Oct 2005 19:54:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9H2sP4c033148 for <[e-mail]>; Sun, 16 Oct 2005 19:54:25 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9H2sO4S032017 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 16 Oct 2005 19:54:25 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j9H2sO4S032017
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=N8eyu3akhRtp0vQMkgXisBVPJsuPzQCdmQkPXPxG/UxSu6OQeqYXXLUXo611RhvkG 0T16GmIP/9mscCphGwRNpxkKQS8Mgh2OPFtxXvq3X73og3qlDVYszKzyr9VBhH2Zn39 zPy6pJoTcIODhcorOyD4LkRLrPJyByQPqR/ZIgI=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j9H2sOCU044037; Sun, 16 Oct 2005 19:54:24 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
From: Philip Guenther <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Sun, 16 Oct 2005 19:54:24 -0700
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>

Alexey Melnikov <[e-mail]> writes:
>Philip Guenther wrote:
>>In section 1, I suggest changing
>>   Sieve interpreters that don't support integration with IMAP SHOULD
>>   ignore this extension.
>>to
>>   This extension is only appropriate for sieve interpreters that
>>   support integration with IMAP.
>>(What does it mean for an interpreter to 'ignore' an extension?)
>>
>I still the original sentence is better. Below are some examples that
>explain the motivation for this sentence:
...

Even with the examples, I still can't be sure what you mean by
"ignore".

Should the implementation "ignore the extension" by not supporting it,
returning error if it's used with 'require'?  (This is what I originally
thought you meant and was the goal of my suggested rewording.)

Should it make its appearance in a 'require' a no-op, causing an error
later if any of the *flag actions or test are actually used?

Should it make the 'addflag' and 'removeflag' actions no-ops and the
'hasflag' test always return false?

Should it support the *flag actions and test completely and ignore only
the effect on the 'keep' and 'fileinto' actions?


I now _suspect_ the last is what you mean, in which case the extension
should perhaps be called the "atomset" extension, as all you're certain
of getting when you require it is the ability to manipulate sets of
atoms.  (Okay, I'm being slightly facetious there, but only slightly.)


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GN1QGZ008031; Sun, 16 Oct 2005 16:01:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GN1QCI008030; Sun, 16 Oct 2005 16:01:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GN1OMp008023 for <[e-mail]>; Sun, 16 Oct 2005 16:01:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.2] (pool-141-151-161-45.pitt.east.verizon.net [141.151.161.45]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j9GMtAuG007637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 16 Oct 2005 18:55:14 -0400
Date: Sun, 16 Oct 2005 19:01:18 -0400
From: Cyrus Daboo <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Vacation extension - final comments please
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
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 folks,
The working group last call on the vacation extension was completed several 
weeks ago. I need to have yes/no response from anyone that has reviewed 
this document prior to sending to the IESG. If you have reviewed it please 
send me privately your response so we can move ahead with submitting this 
draft to IESG. I do need this asap as we want to get this to the IESG this 
week.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GIEZqN065029; Sun, 16 Oct 2005 11:16:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GHVJE9034985; Sun, 16 Oct 2005 10:31:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHVHMX034977 for <[e-mail]>; Sun, 16 Oct 2005 10:31:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 16 Oct 2005 18:31:11 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Oct 2005 16:13:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Michael Haardt wrote:

>On Fri, Oct 14, 2005 at 02:53:48PM +0100, Alexey Melnikov wrote:
>  
>
>>>How about:
>>>
>>>The implementation of a notification mechanism may modify the
>>>final message, e.g. truncating it, if it exceeds a length limit,
>>>or modify characters that can not be represented in the
>>>target character set.  The implementation SHOULD keep such
>>>modifications to a minimum.
>>>      
>>>
>>My current text is:
>>   The notification method must also specified how Unicode
>>   characters that that can't be represented by the notification method
>>   are to be handled. Notification methods MUST be able to represent any
>>   US-ASCII character with exception of control characters.
>>
>>Should I just replace it with what you've suggested, or do people feel 
>>that the last sentence is appropriate?
>>    
>>
>
>IA5, the GSM character set, does not contain a backquote character
>(US-ASCII dec. 96).  There goes "any US-ASCII character".  Do pagers
>still exist? The devices I remember from the past contained only numbers.
>  
>
Ok, you've convinced me. I've used your text with minor editorial changes.
I've also replaced the last sentence with:

    Allowed modifications should be documented in a standard track or an 
informational document.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GIEZqJ065029; Sun, 16 Oct 2005 11:16:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GHVJoF034991; Sun, 16 Oct 2005 10:31:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHVHMY034977 for <[e-mail]>; Sun, 16 Oct 2005 10:31:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 16 Oct 2005 18:31:16 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Oct 2005 16:33:46 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: List of issues with Sieve notifications
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

I've incorporated several other changes, the most important are:
1). Clarify that notify doesn't report which actions were taken.
2). Added text about URI validation.
3). Changed priority into a string containing number (currently "1", "2" 
and "3") (Nigel)

Would people prefer to use "high"/"normal"/"low" instead? I though that 
we might want to use relational on the priority, thus it is a number for 
now.

I still have some mailing list messages I need to review, but here is my 
current list of open issues/suggested changes.

1). Need to change the extension name, as there were too many 
incompatible changes.
2). Don't send any notification if no method is given and none 
configured. (Michael)
3). Extend text about URI syntactic/semantic validity. (Michael)
4). Added :from parameter to notify. (Michael)
5). Describe mailto: notification method. (Michael and Ned)
6). Add example about extracting message body. (suggestion from Kjetil)
7). Remove denotify. (many).

I think there is a consensus for doing #7, but I will do it in the next 
revision. I need to rewrite existing examples to make sure that 
variables + notify action are as good as notify + denotify actions. I 
suspect it would be, but I need to do some homework first.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHW24W035555; Sun, 16 Oct 2005 10:32:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GHW2dn035554; Sun, 16 Oct 2005 10:32:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHW1DE035519 for <[e-mail]>; Sun, 16 Oct 2005 10:32:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 16 Oct 2005 18:31:31 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Oct 2005 18:07:43 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>>   If an URI schema is specified that the implementation does not
>>   support, the notification MUST be ignored.
>>    
>>
>
>I still do not particularly like that, but if it is required by
>technical reasons, I can live with it.  To me, it is odd if a
>typo in the URI scheme is ignored, but typos later on cause errors.
>
You have a point: it is not possible to distinguish a mistyped URI 
schema name from an unsupported URI type.

The case I had in mind is as follows: The notification URI is stored 
elsewhere (as an LDAP attribute or an IMAP annotation) and Sieve scripts 
uses Sieve variables extension to specify the notification method. Is it 
desirable for an unrecognized notification method to cause runtime 
error? I am open to suggestions.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHW2Lo035547; Sun, 16 Oct 2005 10:32:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GHW2NL035544; Sun, 16 Oct 2005 10:32:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GHW1DD035519 for <[e-mail]>; Sun, 16 Oct 2005 10:32:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 16 Oct 2005 18:31:23 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Oct 2005 17:50:29 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: "Mark E. Mallett" <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Mark E. Mallett wrote:

>As for a few specific comments (pared down a little):
>
>    > 1.  Introduction
>    > 
>    > This is an extension to the Sieve language defined by [SIEVE] for
>    > providing instant notifications of sieve actions that have been
>    > preformed. It defines the new action "notify".
>
>That definition suggests that executing the "notify" action will cause
>a notification.
>  
>
Right. I've deleted the rest of the sentence after "for providing 
instant notifications".

>    > 1.0
>    > 
>    > Sieve interpreters for which notifications are impractical or is not
>    > possible SHOULD ignore this extension.
>
>What does this mean... are you recommending that interpreters implement
>the extension as no-ops, so that the "require" will work but the actual
>notify statements will not?  I mean, this seems to be recommending
>something other than the usual thing of having the "require" fail to
>operate if the capability is not available.  If all this means is
>"have the 'require' fail if the capability isn't available" -- doesn't
>that go without saying?
>  
>
You are right, this is meaningless and I've deleted the sentence.

[...]

>
>
>> The notify action is compatible with itself.
>
>Meaning?
>
Meaning that multiple executed notify actions are allowed. I've changed 
the sentence to read:

    The notify action is compatible with all actions.
    Multiple executed notify actions are allowed.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ELwNHm058410; Fri, 14 Oct 2005 14:58:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ELwNes058409; Fri, 14 Oct 2005 14:58:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ELwMu8058392 for <[e-mail]>; Fri, 14 Oct 2005 14:58:22 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 14 Oct 2005 14:58:13 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1129327093; h=Date: 	 From:Subject:MIME-version:Content-type; b=GsL6pGihiYJ0ybqXCygXPr23f OoYOKxHclJYdM0vCXnIvzRRf8xVWel9sgwla6vcxFYFWNTELJRo7zydFoEP6w==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 14 Oct 2005 14:58:05 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 14 Oct 2005 14:03:32 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve notification draft
In-reply-to: "Your message dated Fri, 14 Oct 2005 17:48:44 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> On Fri, Oct 14, 2005 at 02:53:48PM +0100, Alexey Melnikov wrote:
> > >How about:
> > >
> > >The implementation of a notification mechanism may modify the
> > >final message, e.g. truncating it, if it exceeds a length limit,
> > >or modify characters that can not be represented in the
> > >target character set.  The implementation SHOULD keep such
> > >modifications to a minimum.
> > >

> > My current text is:
> >    The notification method must also specified how Unicode
> >    characters that that can't be represented by the notification method
> >    are to be handled. Notification methods MUST be able to represent any
> >    US-ASCII character with exception of control characters.
> >
> > Should I just replace it with what you've suggested, or do people feel
> > that the last sentence is appropriate?

> IA5, the GSM character set, does not contain a backquote character
> (US-ASCII dec. 96).  There goes "any US-ASCII character".  Do pagers
> still exist? The devices I remember from the past contained only numbers.

A small point of clarification here: IA5 and the GSM 03.38 character set are
not the same, and IA5 does include grave accent (aka backquote) as one of its
"IRV graphic character allocations".

These days IA5 is for all intents and purposes the same as US-ASCII. (The
variants that include things like the universal currency sign rather than
dollar sign are rarely used.) The GSM charset, on the other hand, has no direct
representation for most of the IRV graphic characters and does include a bunch
of characters that aren't in IA5 or ASCII (e.g., an ae ligature).

In any case, specifications of mappings to various more restrictive charsets
have been widely used for a long time and seem to work pretty well. X.400-1984
discusses several such mappings in detail, for example. I would therefore
suggest changing the text from "able to represent" to "able to handle" or
something similar.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EFmn6k022237; Fri, 14 Oct 2005 08:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EFmnxf022236; Fri, 14 Oct 2005 08:48:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EFmmuZ022220 for <[e-mail]>; Fri, 14 Oct 2005 08:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQRnb-0007wg-PM for [e-mail]; Fri, 14 Oct 2005 17:48:47 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EQRnb-0007yn-N3 for [e-mail]; Fri, 14 Oct 2005 17:48:47 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQRnY-0000ay-9Q for [e-mail]; Fri, 14 Oct 2005 17:48:44 +0200
Date: Fri, 14 Oct 2005 17:48:44 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Fri, Oct 14, 2005 at 02:53:48PM +0100, Alexey Melnikov wrote:
> >How about:
> >
> >The implementation of a notification mechanism may modify the
> >final message, e.g. truncating it, if it exceeds a length limit,
> >or modify characters that can not be represented in the
> >target character set.  The implementation SHOULD keep such
> >modifications to a minimum.
> > 

> My current text is:
>    The notification method must also specified how Unicode
>    characters that that can't be represented by the notification method
>    are to be handled. Notification methods MUST be able to represent any
>    US-ASCII character with exception of control characters.
> 
> Should I just replace it with what you've suggested, or do people feel 
> that the last sentence is appropriate?

IA5, the GSM character set, does not contain a backquote character
(US-ASCII dec. 96).  There goes "any US-ASCII character".  Do pagers
still exist? The devices I remember from the past contained only numbers.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EDrrUw089649; Fri, 14 Oct 2005 06:53:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EDrrC3089648; Fri, 14 Oct 2005 06:53:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EDrrhe089641 for <[e-mail]>; Fri, 14 Oct 2005 06:53:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 14:53:50 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Oct 2005 14:53:48 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Michael Haardt wrote:

>On Thu, Oct 13, 2005 at 11:31:20PM +0100, Alexey Melnikov wrote:
>  
>
>>I think the best we can do is to say that a notification mechanism 
>>specified how characters that can't be represented by the notification 
>>method must be handled handled.
>>    
>>
>
>How about:
>
>The implementation of a notification mechanism may modify the
>final message, e.g. truncating it, if it exceeds a length limit,
>or modify characters that can not be represented in the
>target character set.  The implementation SHOULD keep such
>modifications to a minimum.
>  
>
My current text is:
    The notification method must also specified how Unicode
    characters that that can't be represented by the notification method
    are to be handled. Notification methods MUST be able to represent any
    US-ASCII character with exception of control characters.

Should I just replace it with what you've suggested, or do people feel 
that the last sentence is appropriate?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EDaIfV084638; Fri, 14 Oct 2005 06:36:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EDaIsc084637; Fri, 14 Oct 2005 06:36:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EDaHBN084626 for <[e-mail]>; Fri, 14 Oct 2005 06:36:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQPjM-00029q-Fm for [e-mail]; Fri, 14 Oct 2005 15:36:16 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EQPjM-0007y1-DM for [e-mail]; Fri, 14 Oct 2005 15:36:16 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQPjJ-0000UR-1k for [e-mail]; Fri, 14 Oct 2005 15:36:13 +0200
Date: Fri, 14 Oct 2005 15:36:13 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Fri, Oct 14, 2005 at 02:05:02PM +0100, Alexey Melnikov wrote:
> How about the following:
> 
>    An implementation MAY enforce
>    other semantical restrictions on URIs, for example an SMS URI can only
>    contain phone numbers in a particular geographical reason. Violation
>    of such semantical restrictions MUST also cause an error.

Semantical restrictions is exactly the term I couldn't put into words!

Is the MUST useful? If an implementation wants to ignore violating such
restrictions, it could just pretend there are no restrictions and let
things fail silently, hence it it not forced to treat them as error,
despite the MUST.

The above would make sense if absence of errors would guarantee delivery
of a notification (making notify transactional), but unless semantic
validity could be checked completely, I see no way to offer that.

Compared to the original specification that enforced errors for
syntactically invalid URLs and allowed them for nothing else, I would
like to additionally allow generating errors upon semantic restrictions,
but not enforce them.

While saying that, we have a similar situation with "redirect".
Would anybody object if "redirect" caused an error for syntactically
valid addresses that violate e.g. a site policy of not allowing mail to
be forwarded to external addresses? Some sites may check that in the
central mail hub, thus not allowing to detect the error inside Sieve
and ignoring it.

Kind of like: If I can detect a violation, I flag an error, but if I
can't until it is too late, I ignore it.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ED59QU075494; Fri, 14 Oct 2005 06:05:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ED59Gw075487; Fri, 14 Oct 2005 06:05:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ED58j2075456 for <[e-mail]>; Fri, 14 Oct 2005 06:05:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 14:05:03 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Oct 2005 14:05:02 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Michael Haardt wrote:

>>And later:
>>   If the :method tag contains a supported URI schema, then the URI MUST
>>   be checked for syntactic validity. An invalid URI syntax or an
>>   unsupported URI extension MUST cause an error.
>>   
>>
>
>May I add:
>
>A semantically invalid URI may cause an error?
>
>That would allow me to cause errors for phone numbers my implementation
>knows to be crap, although they are syntactically valid.
>  
>
How about the following:

    An implementation MAY enforce
    other semantical restrictions on URIs, for example an SMS URI can only
    contain phone numbers in a particular geographical reason. Violation
    of such semantical restrictions MUST also cause an error.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ECgF0g069094; Fri, 14 Oct 2005 05:42:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ECgFRI069093; Fri, 14 Oct 2005 05:42:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ECgEDJ069083 for <[e-mail]>; Fri, 14 Oct 2005 05:42:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 13:42:01 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Oct 2005 13:42:00 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Philip Guenther wrote:

>In section 1, I suggest changing
>   Sieve interpreters that don't support integration with IMAP SHOULD
>   ignore this extension.
>to
>   This extension is only appropriate for sieve interpreters that
>   support integration with IMAP.
>(What does it mean for an interpreter to 'ignore' an extension?)
>
I still the original sentence is better. Below are some examples that explain the motivation for this sentence:

1). Somebody writes a generic Sieve implementation that uses callbacks for specific functions like get a header field or set a flag. For example Cyrus Sieve implementation.

The generic implementation can recognize presence of imap4flags, but might be unable to set an IMAP flag, because the application hasn't provided a callback for setting flags.

(Arguably one can treat this as a bug, so maybe the following example is more interesting.)

2). A particular installation might not be able to set IMAP flags, because it uses a proprietary API for message delivery and the configured mailstore backend doesn't support IMAP flags.

3). Even if integration with an IMAP mailstore is supported, this doesn't guaranty that a particular mailstore backend would support setting IMAP flags.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EBYXN6051516; Fri, 14 Oct 2005 04:34:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EBYXoH051515; Fri, 14 Oct 2005 04:34:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EBYW2j051507 for <[e-mail]>; Fri, 14 Oct 2005 04:34:32 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQNpX-00084T-Nw for [e-mail]; Fri, 14 Oct 2005 13:34:31 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1EQNpX-0005u2-JA for [e-mail]; Fri, 14 Oct 2005 13:34:31 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQNpW-0000QI-2Z for [e-mail]; Fri, 14 Oct 2005 13:34:30 +0200
Date: Fri, 14 Oct 2005 13:34:30 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Fri, Oct 14, 2005 at 11:38:35AM +0100, Alexey Melnikov wrote:
> Michael Haardt wrote:
> 
> >>   Usage:   notify [":method" string]
> >>              [":id" string]
> >>              [<":low" / ":normal" / ":high">]
> >>              [":message" string]    
> >>
> >
> >I miss a sender specification of some kind, like [":from" string], like
> >we have for vacation.
> 
> So you want to distinguish between notifications caused by messages
> being delivered into different accounts?
> 
> Fine with me, as long as it is optional.

Some notification methods, like SMS, support the concept of a sender.
I just want to be able to influence that, perhaps even different senders
for the same account.  I see some similarity between notify and vacation,
and suggest, as written in section 4.3 of the vacation draft:

   Implementations MAY also impose restrictions
   on what addresses can specified in a ":from" parameter; it is
   suggested that values which fail such a security check simply be
   ignored rather than causing the vacation action to fail.

Reading that, shouldn't it be listed under "security considerations"
as well?

>    The format of the notification is implementation-defined and
>    is also affected by the notification method used (see below).
>    However, all content specified in the notify action SHOULD be
>    included. It is RECOMMENDED that a timestamp is included in
>    the notification. Implementations SHOULD NOT include extraneous
>    information.
> 
> This should eliminate any confusion.

Yes, that is very clear.

> >What if the user is over quota
> >or the remote host is down? That's not a successful delivery.  Yet I would
> >like to get a notification that the mail was seen by the filter.
> >
> In my implementation overquota checks are done after Sieve, so
> notifications will be always sent.

Same here.

>    If an URI schema is specified that the implementation does not
>    support, the notification MUST be ignored.

I still do not particularly like that, but if it is required by
technical reasons, I can live with it.  To me, it is odd if a
typo in the URI scheme is ignored, but typos later on cause errors.

> And later:
>    If the :method tag contains a supported URI schema, then the URI MUST
>    be checked for syntactic validity. An invalid URI syntax or an
>    unsupported URI extension MUST cause an error.

May I add:

A semantically invalid URI may cause an error?

That would allow me to cause errors for phone numbers my implementation
knows to be crap, although they are syntactically valid.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EBJYSm047146; Fri, 14 Oct 2005 04:19:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EBJYV2047145; Fri, 14 Oct 2005 04:19:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EBJXcO047137 for <[e-mail]>; Fri, 14 Oct 2005 04:19:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQNb1-0000yK-Ua for [e-mail]; Fri, 14 Oct 2005 13:19:32 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1EQNb1-0005WS-RB for [e-mail]; Fri, 14 Oct 2005 13:19:31 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQNb1-0000Pb-Mg for [e-mail]; Fri, 14 Oct 2005 13:19:31 +0200
Date: Fri, 14 Oct 2005 13:19:31 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 13, 2005 at 11:31:20PM +0100, Alexey Melnikov wrote:
> I think the best we can do is to say that a notification mechanism 
> specified how characters that can't be represented by the notification 
> method must be handled handled.

How about:

The implementation of a notification mechanism may modify the
final message, e.g. truncating it, if it exceeds a length limit,
or modify characters that can not be represented in the
target character set.  The implementation SHOULD keep such
modifications to a minimum.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAcgNg034924; Fri, 14 Oct 2005 03:38:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EAcg7J034923; Fri, 14 Oct 2005 03:38:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAcfhU034909 for <[e-mail]>; Fri, 14 Oct 2005 03:38:41 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 11:38:37 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Oct 2005 11:38:35 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>>    Usage:   notify [":method" string]
>>               [":id" string]
>>               [<":low" / ":normal" / ":high">]
>>               [":message" string]    
>>
>
>I miss a sender specification of some kind, like [":from" string], like
>we have for vacation.

So you want to distinguish between notifications caused by messages
being delivered into different accounts?

Fine with me, as long as it is optional.

>>    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 errors occurred in
>>    another action they SHOULD be reported in the notification. In
>>    addition, if the notification method does not provide a timestamp,
>>    one SHOULD be appended to the notification. Implementations SHOULD
>>    NOT include extraneous information.
>
>I don't like that, because it means I have to delay sending notifications
>until successful delivery of a message, like transferring it to the mail
>store or forwarding it to another host.

Based on numerous comments I've updated the paragraph to read:

    The format of the notification is implementation-defined and
    is also affected by the notification method used (see below).
    However, all content specified in the notify action SHOULD be
    included. It is RECOMMENDED that a timestamp is included in
    the notification. Implementations SHOULD NOT include extraneous
    information.

This should eliminate any confusion.

>What if the user is over quota
>or the remote host is down? That's not a successful delivery.  Yet I would
>like to get a notification that the mail was seen by the filter.
>
In my implementation overquota checks are done after Sieve, so
notifications will be always sent.

Anyway, I hope the new text clarifies this.

>I guess what I do not like it that notify sounds like DSNs.  To me,
>it should be just some action.  If I decide to send a notification and
>then discard the message in order to process mail alarms, I don't need
>to have notify tell me the message was discarded.
>
>>    If the :method tag is not specified, the default
>>    implementation defined notification method is used.  The
>>    possible values of this will be site-specific.  If an URI schema is
>>    specified that the implementation does not support, the notification
>>    MUST be ignored. An implementation treats this as a warning
>>    condition and execution of the sieve script MUST continue.
>>    
>
>As I wrote in another mail, people have a hard time to get phone numbers
>right, like not including letters in them.  I prefer to generate errors
>if that happens.  That way they see something is wrong instead of yelling
>at the SMS provider.

Ok, the new text reads:

    If an URI schema is specified that the implementation does not
    support, the notification MUST be ignored.

And later:
    If the :method tag contains a supported URI schema, then the URI MUST
    be checked for syntactic validity. An invalid URI syntax or an
    unsupported URI extension MUST cause an error.

>May an implementation choose not to send any notification if no method is
>given? I run a bunch of systems without a default notification mechanism.

I am Ok with that, but I would like to hear more opinions.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAbnLO034610; Fri, 14 Oct 2005 03:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EAbns9034609; Fri, 14 Oct 2005 03:37:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAbmdC034591 for <[e-mail]>; Fri, 14 Oct 2005 03:37:48 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 11:37:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 23:31:20 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>On Tue, Sep 27, 2005 at 05:56:04PM +0200, Kjetil Torgrim Homme wrote:
>  
>
>>one general issue which I think should be specified in 3.1, is how to
>>handle charsets when the notification method doesn't support full UTF-8.
>>something like: "Characters in the message which can't be represented by
>>the notification method SHOULD be replaced with a symbol indicating an
>>unknown character, e.g., a question mark."
>>    
>>
>
>Forget about that.  If you connect to a SMSC and speak UCP, it is your
>choice how to convert the message text to IA5.  If you use a regular
>gateway by SMTP or HTTP, you can not deliver IA5, but usually ISO-8859-15,
>and you have no influence on how that is converted to IA5.  The ones I
>saw so far just dropped characters they can not translate.
>  
>
I think the best we can do is to say that a notification mechanism 
specified how characters that can't be represented by the notification 
method must be handled handled.

>I choose to use UCP, if I can, but it is not offered by all SMS providers.
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EA1mIo023999; Fri, 14 Oct 2005 03:01:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EA1m7V023998; Fri, 14 Oct 2005 03:01:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EA1kTo023989 for <[e-mail]>; Fri, 14 Oct 2005 03:01:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQMNl-00086A-Kx for [e-mail]; Fri, 14 Oct 2005 12:01:45 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EQMNl-0003KF-BO for [e-mail]; Fri, 14 Oct 2005 12:01:45 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQMNi-0000KA-In for [e-mail]; Fri, 14 Oct 2005 12:01:42 +0200
Date: Fri, 14 Oct 2005 12:01:42 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Thu, Oct 13, 2005 at 11:12:47AM +0100, Dave Cridland wrote:
> If you're really intent on having some mechanism to test for "raw" 
> features of the header content, then my personal view is that there 
> needs to be a "header" test, which normalizes whitespace, strips 
> header and footer, and decodes RFC2047, and a "rawheader", which 
> provides the header field value with all spaces, encoded words, etc, 
> intact.

Thinking about it, I suspected a new test might be useful in a
past mail of mine, too.  So that may indeed be the way out.

> The majority of people will intend that "banana" matches "Subject: 
> banana ", "Subject: =?Q?iso-8859-1?banana?=", and "Subject:banana" 
> and all other variations - the golden rule being if it looks as it it 
> ought to have matched when they observe it in the MUA, then it ought 
> to have matched.

Hmm.  I can't think of anything that weakens that point.  If MUAs would
display trailing spaces, things might be different, but they don't.

So you have me convinced: The header test should strip trailing white
space and next time I get hit by a spammer where this bites, I shall
think about specifying a new test operating on raw headers.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E7Kahl001159; Fri, 14 Oct 2005 00:20:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9E7Kaae001158; Fri, 14 Oct 2005 00:20:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E7KYR9001150 for <[e-mail]>; Fri, 14 Oct 2005 00:20:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQJrl-0000fK-IW for [e-mail]; Fri, 14 Oct 2005 09:20:33 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53-RC2 #21) id 1EQJrl-00045y-0M for [e-mail]; Fri, 14 Oct 2005 09:20:33 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQJrh-0000to-6Z for [e-mail]; Fri, 14 Oct 2005 09:20:29 +0200
Date: Fri, 14 Oct 2005 09:20:29 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

> On Thu, 2005-10-13 at 22:25 -0400, Barry Leiba wrote:
> > Can we resolve this with respect to "relational", so I can get another 
> > draft out?  As I see it, we're all happy with taking the "stripping" 
> > language out of "relational", and the uncertainty is whether and where 
> > it belongs in the base spec.  Right?
> > 
> > So how about I change "relational", and we change the subject line on 
> > future iterations of this discussion, to replace "relational draft" with 
> > "base spec"?

I would appreciate that, too.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E2hda6051081; Thu, 13 Oct 2005 19:43:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9E2hdCI051080; Thu, 13 Oct 2005 19:43:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E2hciJ051053 for <[e-mail]>; Thu, 13 Oct 2005 19:43:38 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EQFXi-0005SD-AW; Fri, 14 Oct 2005 04:43:34 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EQFXd-0004t4-Vs; Fri, 14 Oct 2005 04:43:30 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Fri, 14 Oct 2005 04:43:23 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.7, required 12, autolearn=disabled, AWL 1.11, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Thu, 2005-10-13 at 22:25 -0400, Barry Leiba wrote:
> Can we resolve this with respect to "relational", so I can get another 
> draft out?  As I see it, we're all happy with taking the "stripping" 
> language out of "relational", and the uncertainty is whether and where 
> it belongs in the base spec.  Right?
> 
> So how about I change "relational", and we change the subject line on 
> future iterations of this discussion, to replace "relational draft" with 
> "base spec"?

sounds good to me.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E2PIWu045556; Thu, 13 Oct 2005 19:25:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9E2PIeF045555; Thu, 13 Oct 2005 19:25:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9E2PH9N045539 for <[e-mail]>; Thu, 13 Oct 2005 19:25:17 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9E2R1hJ006370 for <[e-mail]>; Thu, 13 Oct 2005 22:27:01 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9E2PB8100914 for <[e-mail]>; Thu, 13 Oct 2005 22:25:11 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9E2P9u43304 for <[e-mail]>; Thu, 13 Oct 2005 22:25:10 -0400
Received: from SATURN ([9.12.239.153]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129256709.163; Thu, 13 Oct 2005 22:25:09 -0400
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 22:25:09 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

Can we resolve this with respect to "relational", so I can get another 
draft out?  As I see it, we're all happy with taking the "stripping" 
language out of "relational", and the uncertainty is whether and where 
it belongs in the base spec.  Right?

So how about I change "relational", and we change the subject line on 
future iterations of this discussion, to replace "relational draft" with 
"base spec"?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DJahjU006624; Thu, 13 Oct 2005 12:36:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DJahRV006623; Thu, 13 Oct 2005 12:36:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DJag83006607 for <[e-mail]>; Thu, 13 Oct 2005 12:36:42 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9DJcQNZ022595 for <[e-mail]>; Thu, 13 Oct 2005 15:38:26 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9DJaZ8206704 for <[e-mail]>; Thu, 13 Oct 2005 15:36:36 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9DJaZu75738 for <[e-mail]>; Thu, 13 Oct 2005 15:36:35 -0400
Received: from saturn ([9.2.43.75]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129232194.109; Thu, 13 Oct 2005 15:36:34 -0400
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 15:36:34 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

Dave Cridland wrote:
> The majority of people will intend that "banana" matches "Subject: 
> banana ", "Subject: =?Q?iso-8859-1?banana?=", and "Subject:banana" and 
> all other variations - the golden rule being if it looks as it it ought 
> to have matched when they observe it in the MUA, then it ought to have 
> matched.

What he said.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DFcevf020096; Thu, 13 Oct 2005 08:38:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DFcdiL020095; Thu, 13 Oct 2005 08:38:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DFccKg020076 for <[e-mail]>; Thu, 13 Oct 2005 08:38:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 13 Oct 2005 16:38:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 16:38:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Proposed agenda for the SIEVE WG meeting in Vancouver
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
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>

Ok folks,
Here is a tentative agenda for the Vancouver IETF meeting.

Agenda

- Introduction (blue sheets, scribe etc) (1 min)
- Agenda Bashing (4 mins)
- Finished documents (Vacation, spamtest, IMAP Flags) (5 mins)
- Base spec discussion (post WGLC comments) (10 mins)
- Relational draft status (10 mins)
- Variables draft (post LC comments) (10 mins)
- Body test draft status (10 mins)
- Edit header draft status (10 mins)
- Notification draft (15 mins)
- Editors for different notification mechanisms (5 mins)
- Reject/refuse draft (20 mins)
- Other business (20 mins)
  - execution of Sieve on flag changes, expunges, etc.
  - index and time extensions
  - include

Total: 120 minutes.

If we resolve all issues with Variables, the corresponding item will disappear from the list.

Comments?


Cyrus & Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DBwjEf064648; Thu, 13 Oct 2005 04:58:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DBwjeH064647; Thu, 13 Oct 2005 04:58:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DBwiGr064637 for <[e-mail]>; Thu, 13 Oct 2005 04:58:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EQ1jN-0001Bx-3T; Thu, 13 Oct 2005 13:58:41 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EQ1jE-0008Ro-07; Thu, 13 Oct 2005 13:58:32 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Thu, 13 Oct 2005 13:58:10 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.636, required 12, autolearn=disabled, AWL 1.18, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Thu, 2005-10-13 at 12:17 +0100, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >+   Some match types mandate stripping of leading and/or trailing
> >+   whitespace from the inputs prior to comparison whenever the string
> >+   value is taken from the message.  In the "string" test, both
> >+   source and key-list are taken from the script, not the message,
> >+   and whitespace stripping MUST NOT be done unless the script
> >+   explicitly requests this through some future mechanism.
> >
> I like the intent of the text, but it seems to be implying that a test 
> can override stripping behavior mandated by a match type.
> I thought we've agreed previously that this is not a good idea.

yes, I agree.  however, it's a cop-out just in case the base spec and
relational don't get changed, because that is (as I see it) how it
stands: ":value" changes the stripping behaviour of all test actions.
the text above isn't normative, anyway.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DBHRCr054911; Thu, 13 Oct 2005 04:17:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DBHRXD054910; Thu, 13 Oct 2005 04:17:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DBHQXu054897 for <[e-mail]>; Thu, 13 Oct 2005 04:17:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 13 Oct 2005 12:17:22 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 12:17:21 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>I want to revert the suggested text and example in "variables" about the
>interaction with "relational", and the new suggested change relative to
>the currently published -06 draft is as follows:
>
>
> 5.  Test string
> 
>    Usage:    string [MATCH-TYPE] [COMPARATOR]
>              <source: string-list> <key-list: string-list>
> 
>    The "string" test evaluates to true if any of the source strings
>    matches any key.  The type of match defaults to ":is".
> 
>+   Some match types mandate stripping of leading and/or trailing
>+   whitespace from the inputs prior to comparison whenever the string
>+   value is taken from the message.  In the "string" test, both
>+   source and key-list are taken from the script, not the message,
>+   and whitespace stripping MUST NOT be done unless the script
>+   explicitly requests this through some future mechanism.
>+
>  
>
I like the intent of the text, but it seems to be implying that a test 
can override stripping behavior mandated by a match type.
I thought we've agreed previously that this is not a good idea.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DAvdWZ050647; Thu, 13 Oct 2005 03:57:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DAvdpc050646; Thu, 13 Oct 2005 03:57:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DAvdZF050640 for <[e-mail]>; Thu, 13 Oct 2005 03:57:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 13 Oct 2005 11:57:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 11:57:35 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Consensus call: stripping leading/trailing spaces
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>>>And I would love to keep this out of the relational extension, if I had
>>>a choice.
>>>      
>>>
>>Agreed.
>>    
>>
>yes, the behaviour really needs to get into the base spec.
>  
>
Do we have a rough consensus to:
1). Move the text about stripping leading/trailing spaces in the 
leftmost parameter from the relational draft to the base spec.
2). Don't strip leading/trailing spaces in the leftmost parameter of the 
string test.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DACt2a042189; Thu, 13 Oct 2005 03:12:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DACtbU042187; Thu, 13 Oct 2005 03:12:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.dave.cridland.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DACsaJ042165 for <[e-mail]>; Thu, 13 Oct 2005 03:12:54 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 2A4FC154009; Thu, 13 Oct 2005 10:12:48 +0000 (UTC)
Date: Thu, 13 Oct 2005 11:12:47 +0100
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

On Thu Oct 13 10:48:54 2005, Michael Haardt wrote:
> On Wed, Oct 12, 2005 at 10:16:21AM -0400, Barry Leiba wrote:
> > >? My implementation evaluates the first test to be true, and the 
> second
> > >to false for all subjects.  Trailing white space is kept and 
> used,
> > >because that was intuitive to me
> > > It's intuitive to you that a message with this line
> >   Subject: banana
> > should NOT match this test
> >   header :is "subject" "banana"
> > ?
> > What, you didn't notice the space character after the word 
> "banana" in > the subject line?  Neither did anyone else.
> 
> In case there was a space after "banana", it's not there any more.
> I am not sure what that means now.

In this case, it's because Barry uses a client which does 
format=flowed text, so it's likely that the client itself stripped 
the space before sending - a trailing space has meaning in 
format=flowed. I don't think this weakens his argument.

If you're really intent on having some mechanism to test for "raw" 
features of the header content, then my personal view is that there 
needs to be a "header" test, which normalizes whitespace, strips 
header and footer, and decodes RFC2047, and a "rawheader", which 
provides the header field value with all spaces, encoded words, etc, 
intact.

The majority of people will intend that "banana" matches "Subject: 
banana ", "Subject: =?Q?iso-8859-1?banana?=", and "Subject:banana" 
and all other variations - the golden rule being if it looks as it it 
ought to have matched when they observe it in the MUA, then it ought 
to have matched.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DABTXM041904; Thu, 13 Oct 2005 03:11:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DABTib041903; Thu, 13 Oct 2005 03:11:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DABSP7041897 for <[e-mail]>; Thu, 13 Oct 2005 03:11:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EQ03b-0003RZ-IK for [e-mail]; Thu, 13 Oct 2005 12:11:27 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EQ03b-0007Qh-GR for [e-mail]; Thu, 13 Oct 2005 12:11:27 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EQ03U-0002kH-7r for [e-mail]; Thu, 13 Oct 2005 12:11:20 +0200
Date: Thu, 13 Oct 2005 12:11:20 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 12, 2005 at 06:28:32PM -0400, Mark E. Mallett wrote:
> I am mostly in agreement there.  In header tests, my implementation only
> strips leading spaces, but only because that is what I believed a script
> writer would expect (and, as I mentioned before, is the only way some of
> the examples could work).  I could probably get on board with stripping
> trailing spaces from header tests for consistency's sake, but do not do
> it at present.

Ok, so are there any votes against stripping leading white space on
header tests? I don't see agreement on how to treat trailing space
yet, but that's a different issue.

> Unfortunately I can envision a situation where a script writer might want
> to test for sequences of leading and, particularly, trailing spaces.
> But you can't really have it both ways without adding some kind of other
> options.

Indeed, and you can not test for the white space between the header
name and the colon either.  I guess that needs a new test operating on
raw headers.

> As for address elements, I believe I am stripping whitespace only if the
> address is not in anglebrackets, but if anglebrackets are present, am
> taking the interior as the literal string.  Kjetil's comments about
> address canonicalization for the tests are interesting though; I had
> thought of the address test as a string comparison against the character
> strings found in the message header, not as a semantic test (i.e. against
> what the address means).  But that interpretation has a lot of appeal
> and I am at the moment inclined to change.

Note that the base spec requires to strip comments within addresses.
But indeed it is not clearly spelled out that e.g. quoted local parts
are to be matched unquoted.  Yet another change to the base spec.  We
discussed that before, but that might have got lost.

> > If white space
> > is stripped on the left side (message value), it should be stripped on the
> > right side (literal) the same way, but that is an independent issue.
> 
> I agree with the last part, but not the first :-)  I think that the
> space-stripping conversation should be focused on the test inputs that
> the script writer doesn't explicitly control, i.e. to the inputs that
> are supplied by the implementation "from the message."  If the script writer
> supplies a literal with spaces in it, and it doesn't make sense, well
> that's a script bug.  The script writer has the ability to repair that
> mistake.

You have a point there.

> Ditto.  But your description of your implementation seems to contradict
> your belief (quoted above) that spaces should be stripped from literal
> strings if they have been stripped from another input to the test.
> Do I misunderstand?

Oops.  No.  I guess I thought "if it doesn't say it strips trailing
space, it should be kept" and reading your answer above, I agree that
it is really better that way.

I like symmetry a lot, but get carried away with it sometimes.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D9nsjL038665; Thu, 13 Oct 2005 02:49:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9D9nsYL038664; Thu, 13 Oct 2005 02:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D9nr06038648 for <[e-mail]>; Thu, 13 Oct 2005 02:49:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EPzii-0001sy-1V for [e-mail]; Thu, 13 Oct 2005 11:49:52 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EPzih-0003jm-Ou for [e-mail]; Thu, 13 Oct 2005 11:49:51 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EPzhm-0001dA-3t for [e-mail]; Thu, 13 Oct 2005 11:49:09 +0200
Date: Thu, 13 Oct 2005 11:48:54 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 12, 2005 at 10:16:21AM -0400, Barry Leiba wrote:
> >? My implementation evaluates the first test to be true, and the second
> >to false for all subjects.  Trailing white space is kept and used,
> >because that was intuitive to me
> 
> It's intuitive to you that a message with this line
>   Subject: banana
> should NOT match this test
>   header :is "subject" "banana"
> ?
> What, you didn't notice the space character after the word "banana" in 
> the subject line?  Neither did anyone else.

In case there was a space after "banana", it's not there any more.
I am not sure what that means now.

But right, I did not notice it, even if it would have been there.  To me,
that says clients should possibly mark trailing space somehow.  I'll put
it on my list of mail client misfeatures. ;)

At one time I used a filter that matched (together with other tests) a
trailing space, because a really annoying spammer used it.  Worked well
until the spam stopped.  That's real enough to me for wanting things to
work that way, but I am not religious on this, if the majority decides
it should be stripped on header tests.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D1L0px091751; Wed, 12 Oct 2005 18:21:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9D1L0SN091750; Wed, 12 Oct 2005 18:21:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D1KwBY091740 for <[e-mail]>; Wed, 12 Oct 2005 18:20:58 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1EPrmA-0002NV-7k; Thu, 13 Oct 2005 03:20:54 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EPrm6-0002Vt-I7; Thu, 13 Oct 2005 03:20:50 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 13 Oct 2005 03:20:37 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.637, required 12, autolearn=disabled, AWL 1.18, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-12 at 18:28 -0400, Mark E. Mallett wrote:
> > If white space
> > is stripped on the left side (message value), it should be stripped on the
> > right side (literal) the same way, but that is an independent issue.
> 
> I agree with the last part, but not the first :-)  I think that the
> space-stripping conversation should be focused on the test inputs that
> the script writer doesn't explicitly control, i.e. to the inputs that
> are supplied by the implementation "from the message."  If the script writer
> supplies a literal with spaces in it, and it doesn't make sense, well
> that's a script bug.  The script writer has the ability to repair that
> mistake.

I think this makes sense.  consider this example:

        require "variables";
        if header :matches "Subject" "*" {
                set "subject" "${1}";
        }
        if string :is "${subject}" "devious" ...

if the message contains "Subject: devious ", the "string" test should
IMO succeed, *but* the stripping didn't happen there -- it should be
done by the "header" test.  in other words, ${1} contained "devious"
without the trailing space since the "Subject" value was stripped.

I want to revert the suggested text and example in "variables" about the
interaction with "relational", and the new suggested change relative to
the currently published -06 draft is as follows:


 5.  Test string
 
    Usage:    string [MATCH-TYPE] [COMPARATOR]
              <source: string-list> <key-list: string-list>
 
    The "string" test evaluates to true if any of the source strings
    matches any key.  The type of match defaults to ":is".
 
+   Some match types mandate stripping of leading and/or trailing
+   whitespace from the inputs prior to comparison whenever the string
+   value is taken from the message.  In the "string" test, both
+   source and key-list are taken from the script, not the message,
+   and whitespace stripping MUST NOT be done unless the script
+   explicitly requests this through some future mechanism.
+
    Example:
       set "state" "${state} pending";
       if string :matches " ${state} " "* pending *" {
           # the above test always succeeds
       }
 
    The "relational" extension [RELATIONAL] adds a match type called
    ":count".  The count of a single string is 0 if it is the empty
    string, or 1 otherwise.  The count of a string list is the sum of the
    counts of the member strings.


forgive my narrow focus on "variables" just now, but I really want to
get the document done.

> > And I would love to keep this out of the relational extension, if I had
> > a choice.
> 
> Agreed.

yes, the behaviour really needs to get into the base spec.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CMSaYd078549; Wed, 12 Oct 2005 15:28:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CMSasA078548; Wed, 12 Oct 2005 15:28:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9CMSZev078541 for <[e-mail]>; Wed, 12 Oct 2005 15:28:35 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 55509 invoked by uid 101); 12 Oct 2005 18:28:32 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 12 Oct 2005 18:28:32 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Wed, Oct 12, 2005 at 12:55:17PM +0200, Michael Haardt wrote:
> 
> I strongly disagree to always stripping white space.  To me, it is
> intuitive to strip leading (not trailing) white space for header tests,
> and no white space at all for address or envelope tests.

I am mostly in agreement there.  In header tests, my implementation only
strips leading spaces, but only because that is what I believed a script
writer would expect (and, as I mentioned before, is the only way some of
the examples could work).  I could probably get on board with stripping
trailing spaces from header tests for consistency's sake, but do not do
it at present.

Unfortunately I can envision a situation where a script writer might want
to test for sequences of leading and, particularly, trailing spaces.
But you can't really have it both ways without adding some kind of other
options.

As for address elements, I believe I am stripping whitespace only if the
address is not in anglebrackets, but if anglebrackets are present, am
taking the interior as the literal string.  Kjetil's comments about
address canonicalization for the tests are interesting though; I had
thought of the address test as a string comparison against the character
strings found in the message header, not as a semantic test (i.e. against
what the address means).  But that interpretation has a lot of appeal
and I am at the moment inclined to change.



> If white space
> is stripped on the left side (message value), it should be stripped on the
> right side (literal) the same way, but that is an independent issue.

I agree with the last part, but not the first :-)  I think that the
space-stripping conversation should be focused on the test inputs that
the script writer doesn't explicitly control, i.e. to the inputs that
are supplied by the implementation "from the message."  If the script writer
supplies a literal with spaces in it, and it doesn't make sense, well
that's a script bug.  The script writer has the ability to repair that
mistake.


> And I would love to keep this out of the relational extension, if I had
> a choice.

Agreed.


> The base specification indeed does not say anything on this, which means
> implementations might differ depending on how the underlying systems
> handles stuff.  Not good [tm].  What do
> 
>   header "subject" "abc"
>   header "subject" " abc"
> 
> yield with different implementations on matching
> 
>   Subject:abc
>   Subject: abc
>   Subject:  abc
> 
> ? My implementation evaluates the first test to be true, and the second
> to false for all subjects.

Ditto.  But your description of your implementation seems to contradict
your belief (quoted above) that spaces should be stripped from literal
strings if they have been stripped from another input to the test.
Do I misunderstand?

Yours,
-mm-  (way behind on everything, still)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CJo20M064026; Wed, 12 Oct 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CJo2uX064025; Wed, 12 Oct 2005 12:50:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CJo16D064019 for <[e-mail]>; Wed, 12 Oct 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPmbx-0000WE-KD; Wed, 12 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-04.txt 
Message-Id: <[e-mail]>
Date: Wed, 12 Oct 2005 15:50:01 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-04.txt
	Pages		: 15
	Date		: 2005-10-12
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-sieve-vacation-04.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-vacation-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-vacation-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CEGTBl029553; Wed, 12 Oct 2005 07:16:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CEGTgP029552; Wed, 12 Oct 2005 07:16:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CEGSqL029543 for <[e-mail]>; Wed, 12 Oct 2005 07:16:28 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9CEIBll018569 for <[e-mail]>; Wed, 12 Oct 2005 10:18:11 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9CEGM8145024 for <[e-mail]>; Wed, 12 Oct 2005 10:16:22 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9CEGLu190610 for <[e-mail]>; Wed, 12 Oct 2005 10:16:21 -0400
Received: from saturn ([9.2.43.75]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129126581.35; Wed, 12 Oct 2005 10:16:21 -0400
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 10:16:21 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:
>   header "subject" "abc"
>   header "subject" " abc"
> 
> yield with different implementations on matching
> 
>   Subject:abc
>   Subject: abc
>   Subject:  abc
> 
> ? My implementation evaluates the first test to be true, and the second
> to false for all subjects.  Trailing white space is kept and used,
> because that was intuitive to me

It's intuitive to you that a message with this line
   Subject: banana
should NOT match this test
   header :is "subject" "banana"
?
What, you didn't notice the space character after the word "banana" in 
the subject line?  Neither did anyone else.

Repeating: I'm saying that I can imagine NO real situation where it 
matters, I can imagine NO ONE really wanting it to work that way, and I 
can imagine a LOT of wasted time trying to figure out why a script 
behaved in an unexpected way on a message.  I also expect that there are 
implementations of mail thingies out there (clients, servers, relays, 
whatever) that would strip that trailing blank from the header anyway, 
so I doubt such a thing could be transmitted reliably even if someone 
DID want to.

I'll believe that there are "IETF process" reasons why we can't change 
this now.  It'll be tough to get me to believe that anyone actively 
WANTS (for a reason better than "What if...?") the preservation of 
trailing white space in these comparisons.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CAwKwe007335; Wed, 12 Oct 2005 03:58:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CAwKqe007333; Wed, 12 Oct 2005 03:58:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CAwICJ007325 for <[e-mail]>; Wed, 12 Oct 2005 03:58:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EPeJN-0004fH-LI for [e-mail]; Wed, 12 Oct 2005 12:58:17 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EPeGt-0007zz-6Y for [e-mail]; Wed, 12 Oct 2005 12:55:45 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #21) id 1EPeGT-00018A-Us for [e-mail]; Wed, 12 Oct 2005 12:55:17 +0200
Date: Wed, 12 Oct 2005 12:55:17 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Tue, Oct 11, 2005 at 09:50:59PM -0400, Barry Leiba wrote:
> As to your example, well, I didn't ask whether you could *contrive* a
> case where it could matter -- clearly, one can.  I asked whether it was
> a sensible thing to expect in reality, and I think it's not.  And my
> experience tells me that it's not.  And my experience tells me that
> allowing for it causes problems, over time.
> 
> If we don't, then someone's implementation is going to turn
>    To:  [e-mail]
> into " [e-mail]", and it'll be forever before someone sorts
> that bug out.

I strongly disagree to always stripping white space.  To me, it is
intuitive to strip leading (not trailing) white space for header tests,
and no white space at all for address or envelope tests.  If white space
is stripped on the left side (message value), it should be stripped on the
right side (literal) the same way, but that is an independent issue.
And I would love to keep this out of the relational extension, if I had
a choice.

The base specification indeed does not say anything on this, which means
implementations might differ depending on how the underlying systems
handles stuff.  Not good [tm].  What do

  header "subject" "abc"
  header "subject" " abc"

yield with different implementations on matching

  Subject:abc
  Subject: abc
  Subject:  abc

? My implementation evaluates the first test to be true, and the second
to false for all subjects.  Trailing white space is kept and used,
because that was intuitive to me, but indeed I should have brought this
up for discussion of the base spec.  It just didn't occur to me it was
really undefined. :-(

Let's first resolve this before proceeding with the relational extension.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9C1p7QO061659; Tue, 11 Oct 2005 18:51:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C1p7MH061658; Tue, 11 Oct 2005 18:51:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9C1p6Y0061649 for <[e-mail]>; Tue, 11 Oct 2005 18:51:07 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9C1qn8n016697 for <[e-mail]>; Tue, 11 Oct 2005 21:52:49 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9C1p08192784 for <[e-mail]>; Tue, 11 Oct 2005 21:51:00 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9C1oxu167338 for <[e-mail]>; Tue, 11 Oct 2005 21:51:00 -0400
Received: from SATURN ([9.12.243.119]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129081859.3305; Tue, 11 Oct 2005 21:50:59 -0400
Date: Tue, 11 Oct 2005 21:50:59 -0400
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

> that's not what "relational" says, it only strips whitespace from
> values taken from the message, in other words the left hand side.

OK, let's think about this sensibly, though.  I could ask Wolfgang, but
I'm quite sure that when he wrote the spec, he just assumed that no one
would write a test that could not possibly match, and if white space is
stripped from the data from the message, a string with leading white
space that's coded in the script can't possibly match it.

The other way around is a pretty stupid case too -- if we strip white
space from strings in the script and not from those from the message,
we'll have messages that can't possibly be matched by any script.

So, clearly, either we strip both, or neither.

Now that we have that settled, we're back to the real question, which
is whether to strip white space.

As to your example, well, I didn't ask whether you could *contrive* a
case where it could matter -- clearly, one can.  I asked whether it was
a sensible thing to expect in reality, and I think it's not.  And my
experience tells me that it's not.  And my experience tells me that
allowing for it causes problems, over time.

If we don't, then someone's implementation is going to turn
   To:  [e-mail]
into " [e-mail]", and it'll be forever before someone sorts
that bug out.

But if consensus has it that we don't strip, then, OK, we don't strip.
But then we "don't strip" on BOTH sides of the equation.  Both, or
neither.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9C0FaOh053270; Tue, 11 Oct 2005 17:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C0FaX[phone]; Tue, 11 Oct 2005 17:15:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9C0FZ8Q053259 for <[e-mail]>; Tue, 11 Oct 2005 17:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1EPUHM-0004Na-6j; Wed, 12 Oct 2005 02:15:32 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EPUHG-0005pc-Gg; Wed, 12 Oct 2005 02:15:26 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Oct 2005 02:15:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.45, required 12, autolearn=disabled, AWL 1.36, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Tue, 2005-10-11 at 19:16 -0400, Barry Leiba wrote:
> >> Well, I think *all* comparisons should strip leading and trailing
> >> white space
> > 
> > would you want the base spec to say that this stripping should be done
> > for _all_ tests?  my feeling is that we may regret that in the future,
> 
> Yes, that is, indeed, what I said (and meant).  Both sides of every
> equation.

that's not what "relational" says, it only strips whitespace from values
taken from the message, in other words the left hand side.

> Why do you think we'll regret it?

I don't know, just a gut feeling.  sooner or later someone will
introduce a test where keeping whitespace is the "intuitive" behaviour?
"string" may be such a test, but even "address" is to some extent.

recall that <"kjetilho"@ifi.uio.no> is semantically equivalent to
<[e-mail]> (RFC 2822, 3.2.5).  therefore, it is IMHO natural
that Sieve simplifies the localpart to 'kjetilho'.  example:

  address :localpart :is "From" "kjetilho"

this test should return true for both addresses.  consider then <" odd
address"@example.com>.  given the canonicalisation rule above, the
"address" test can not test for this value.

this is clearly an edge case, and it may be acceptable to sacrifice it
simply to ensure that all the relevant documents[*] agree on the
behaviour and specify a simple rule.  in my book, a simple rule should
not specify different behaviour for the two "sides" of a comparison.

[*] base, relational and variables
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BNGYdo047516; Tue, 11 Oct 2005 16:16:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BNGYLd047515; Tue, 11 Oct 2005 16:16:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BNGXR7047493 for <[e-mail]>; Tue, 11 Oct 2005 16:16:33 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9BNIGFx030582 for <[e-mail]>; Tue, 11 Oct 2005 19:18:16 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9BNGQ8177362 for <[e-mail]>; Tue, 11 Oct 2005 19:16:27 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9BNGQu117946 for <[e-mail]>; Tue, 11 Oct 2005 19:16:26 -0400
Received: from SATURN ([9.12.233.196]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129072585.3286; Tue, 11 Oct 2005 19:16:25 -0400
Date: Tue, 11 Oct 2005 19:16:25 -0400
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

>> Well, I think *all* comparisons should strip leading and trailing
>> white space
> 
> would you want the base spec to say that this stripping should be done
> for _all_ tests?  my feeling is that we may regret that in the future,

Yes, that is, indeed, what I said (and meant).  Both sides of every
equation.  Why do you think we'll regret it?

As I said, in my experience I have NEVER encountered a situation where
anyone WANTED, say, "xyz" and "xyz " not to match, and I've only seen
it cause time-wasting confusion, as people tried to figure out why
something wasn't working as they expected it to.

But if people think otherwise, I'm happy to go along with it.  It's
just my opinion, here, that's all.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BN5C39045495; Tue, 11 Oct 2005 16:05:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BN5CcX045494; Tue, 11 Oct 2005 16:05:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BN5BF7045484 for <[e-mail]>; Tue, 11 Oct 2005 16:05:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EPTBD-0005Ao-Li; Wed, 12 Oct 2005 01:05:07 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EPTB5-0004tB-9w; Wed, 12 Oct 2005 01:04:59 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Oct 2005 01:04:46 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.737, required 12, autolearn=disabled, AWL 1.08, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Tue, 2005-10-11 at 14:42 -0400, Barry Leiba wrote:
> > do you think a change to the base spec for "header" makes it possible
> > to remove the whitespace stripping rule in "relational"?
> 
> Well, I think *all* comparisons should strip leading and trailing white
> space, and I don't see a problem with stressing that repeatedly.

okay, I count this as a vote for changing the base spec.  since the base
spec is currently silent on this issue, I think it is OK to change
"header", even though this is subtly incompatible with existing
implementations.  I would argue that a silent spec means "don't meddle
with the data", so this needs to be explicit.

would you want the base spec to say that this stripping should be done
for _all_ tests?  my feeling is that we may regret that in the future,
but then it is not proper for "relational" to state that stripping
happens whatever the test type (and why only the LHS?)

in the case of the "string" test, it would need to be explicit whether
stripping is done or not.  if it is done, the workaround example needs
to stay.

I really want to get the _really_ final variables draft out before the
deadline, so I look forward to your comments.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BIgQ1L019631; Tue, 11 Oct 2005 11:42:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BIgQnx019630; Tue, 11 Oct 2005 11:42:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BIgPNr019591 for <[e-mail]>; Tue, 11 Oct 2005 11:42:25 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j9BIi8Ql024186 for <[e-mail]>; Tue, 11 Oct 2005 14:44:08 -0400
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j9BIgG8145122 for <[e-mail]>; Tue, 11 Oct 2005 14:42:19 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j9BIgFu193532 for <[e-mail]>; Tue, 11 Oct 2005 14:42:15 -0400
Received: from saturn ([9.2.43.75]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1129056135.3234; Tue, 11 Oct 2005 14:42:15 -0400
Date: Tue, 11 Oct 2005 14:42:15 -0400
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

> do you think a change to the base spec for "header" makes it possible
> to remove the whitespace stripping rule in "relational"?

Well, I think *all* comparisons should strip leading and trailing white
space, and I don't see a problem with stressing that repeatedly.  In
particular:

1. In my experience it's ALWAYS a glitch when something retains leading
or trailing white space, and I can't recall EVER seeing a case where a
comparison RELIED on that white space remaining (and failing to match a
similar string without it).

2. Not only is it a glitch, but it's a HARD-TO-FIND glitch, which
causes a lot of wasted time.

3. Since "relational" is specifically discussing comparisons, I see
reasonable value, for clarity, in having text there that reminds people
that white space on the ends is ignored.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BCPvBH075991; Tue, 11 Oct 2005 05:25:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BCPvV8075990; Tue, 11 Oct 2005 05:25:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BCPqUO075964 for <[e-mail]>; Tue, 11 Oct 2005 05:25:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 11 Oct 2005 13:25:20 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Oct 2005 13:25:11 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>>Given this perspective, I don't think any of that is specific to the
>>relational extension and doesn't belong there, and it would be better to
>>have more explanation about how the data is extracted from the message
>>in the base document (or whatever document describes the specific
>>action).
>>    
>>
>
>the base document has the tests "address", "envelope", "header",
>"exists" and some others.  of these, only "header" is unclear on which
>part of the header to consider.  I agree it would be useful to add a
>sentence to the base spec making it explicit that the spaces following
>the header field name are ignored.
>  
>
I would really like if this gets us a clean solution to the problem.

Stripping leading spaces in headers is indeed a common practice these days.

>of the published extensions, only "subaddress" has the possibility of
>touching on this issue, but an e-mail address such as
>
>   <"kjetilho+ awkward address"@ifi.uio.no>
>
>seems contrived.  assuming a "+" subaddress separator, I expect the
>source value to include the SPC, i.e., hold the value
>
>   " awkward address"
>
>(without the quotes).  I find this too academic to warrent concern, but
>"subaddress" might do with a clarification of this case.
>
>
>do you think a change to the base spec for "header" makes it possible to
>remove the whitespace stripping rule in "relational"?
>  
>
Any opinions on this?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96AQlak064238; Thu, 6 Oct 2005 03:26:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j96AQkA1064237; Thu, 6 Oct 2005 03:26:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96AQj2k064229 for <[e-mail]>; Thu, 6 Oct 2005 03:26:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.187] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 6 Oct 2005 11:26:33 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Oct 2005 00:06:47 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Philip Guenther wrote:

>I think the third sentence of section 3.2 should be flipped around, if
>just to avoid "MAY NOT" (while "MAY" is an RFC 2119 keyword, "MAY NOT"
>isn't!).  Indeed, I would give the implementation even more leeways,
>ala:
>   The addflag action MAY alter the flag list in any way that leaves the
>   its semantics as a set of case-insensitive words unaltered.  For
>   example, it may reorder the flags, alter the case of the letters in
>   them, or add or remove duplicates or extraneous spaces.  Scripts
>   SHOULD NOT make assumptions about the ordering of flags in lists or
>   the preservation of their case.

Ok.

>Hmm, written like that, that chunk probably belongs in section 3 and not
>3.2, especially when generallized to cover "setflag" and "removeflag" as
>well.

Done.

>The above also obsoletes the second paragraph of section 6 ("A script
>interpreter..."), which seemed oddly placed to me anyway.

As previously suggested - I've removed the section 6.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9600YX0007390; Wed, 5 Oct 2005 17:00:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9600XuT007389; Wed, 5 Oct 2005 17:00:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9600Xhh007380 for <[e-mail]>; Wed, 5 Oct 2005 17:00:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1ENJBV-00034t-HD; Thu, 06 Oct 2005 02:00:29 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ENJBS-0005Jq-GF; Thu, 06 Oct 2005 02:00:26 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 06 Oct 2005 02:00:01 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.721, required 12, autolearn=disabled, AWL 1.09, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-05 at 16:01 -0400, Mark E. Mallett wrote:
> Ditto in address and envelope tests; there should be no spaces in the
> data "from the message" after extraction from the message.  The big
> surprise happens when you try to impute this space-skipping behaviour to
> the matching logic rather than on how to obtain the data for comparison;
> the "string" test doesn't take its data from the message, and it doesn't
> follow that one would expect it to strip spaces from the left side
> argument.

the "string" source could be a message originally.  anyway, I think with
the added note to "variables", this is clear enough.

> Given this perspective, I don't think any of that is specific to the
> relational extension and doesn't belong there, and it would be better to
> have more explanation about how the data is extracted from the message
> in the base document (or whatever document describes the specific
> action).

the base document has the tests "address", "envelope", "header",
"exists" and some others.  of these, only "header" is unclear on which
part of the header to consider.  I agree it would be useful to add a
sentence to the base spec making it explicit that the spaces following
the header field name are ignored.

of the published extensions, only "subaddress" has the possibility of
touching on this issue, but an e-mail address such as

   <"kjetilho+ awkward address"@ifi.uio.no>

seems contrived.  assuming a "+" subaddress separator, I expect the
source value to include the SPC, i.e., hold the value

   " awkward address"

(without the quotes).  I find this too academic to warrent concern, but
"subaddress" might do with a clarification of this case.


do you think a change to the base spec for "header" makes it possible to
remove the whitespace stripping rule in "relational"?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95K20N0083043; Wed, 5 Oct 2005 13:02:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95K20Yx083042; Wed, 5 Oct 2005 13:02:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j95K1wjr083035 for <[e-mail]>; Wed, 5 Oct 2005 13:01:59 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 72230 invoked by uid 101); 5 Oct 2005 16:01:57 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 5 Oct 2005 16:01:57 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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>

On Tue, Oct 04, 2005 at 04:38:12PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2005-10-04 at 15:24 +0200, Michael Haardt wrote:
> > The ease of a new option like ":full" for keeping white space makes me
> > think "bloat", but unfortunately it does add what we ask for without
> > breaking anything.
> 
> we would need to come up with a more precise name for the match-type.
> 
>   if envelope :all :full "lt" "from" "[e-mail]" ...
> 
> what is :all and what is :full?  two alternative names are ":verbatim"
> and ":compare".
> 
> adding a match-type means we would need a new name for the extension, or
> perhaps a separate document for it.  I'm not sure it's worthwhile, as
> there is a known workaround for the stripping in the variables case
> (prefix both values with non-space) and in the header case I doubt any
> script will care.

My perspective was that it was less about match-type than how you derive
the data.  Part of the tricky wording included mentioning whitespace
elimination when a value ("on the left") was extracted from the message.
My earlier response upthread was that this is not really specific to the
relational tests, but specific to how the values are obtained for the
underlying Sieve action.  I ran into this very early on with e.g. the
header action: since in common practice there is at least one space
after the colon in message header fields, you have to strip at least one
leading space in the "value from the message" in order to meet users'
expectations, not to mention making some of the RFC examples work.  And
if you have to strip one-- well, in for a penny, in for a pound.

Ditto in address and envelope tests; there should be no spaces in the
data "from the message" after extraction from the message.  The big
surprise happens when you try to impute this space-skipping behaviour to
the matching logic rather than on how to obtain the data for comparison;
the "string" test doesn't take its data from the message, and it doesn't
follow that one would expect it to strip spaces from the left side
argument.

Given this perspective, I don't think any of that is specific to the
relational extension and doesn't belong there, and it would be better to
have more explanation about how the data is extracted from the message
in the base document (or whatever document describes the specific
action).

Well that's my (possibly contrary) take on it, anyway.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95G9ZrN055831; Wed, 5 Oct 2005 09:09:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95G9ZEM055830; Wed, 5 Oct 2005 09:09:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95G9Y80055823 for <[e-mail]>; Wed, 5 Oct 2005 09:09:34 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ENBpl-0007vy-TI for [e-mail]; Wed, 05 Oct 2005 18:09:33 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ENBpl-0004mn-NR for [e-mail]; Wed, 05 Oct 2005 18:09:33 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1ENBpk-0007pL-CE for [e-mail]; Wed, 05 Oct 2005 18:09:32 +0200
Date: Wed, 5 Oct 2005 18:09:32 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 05, 2005 at 04:54:14PM +0100, Alexey Melnikov wrote:
> >There is still the yet unanswered question if leading or trailing white
> >space on the right side is an error, as it could never be matched by
> >any argument on the left side and is likely a mistake.
> >
> It is a generic problem with the relational extension, so I don't think 
> we need to address it in the variables draft.

Oops, sorry.  I thought you were talking about the relational extension,
but reading it again, you wrote "variables".

> Besides, the right hand side of a string test can contain variables. So 
> I don't think it is a good idea to make leading/trailing whitespaces in 
> the rightmost parameter a runtime error.

Well, with "eq" and "ne" the right hand side can never match the
left, if it contains leading/trailing whitespace.  That's almost
certainly a mistake, but with the other operators it may be desired.
That's why I agree to documenting this issue in the _relational_
draft with an example.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95FsIh1054323; Wed, 5 Oct 2005 08:54:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95FsI27054322; Wed, 5 Oct 2005 08:54:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95FsHw8054312 for <[e-mail]>; Wed, 5 Oct 2005 08:54:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 5 Oct 2005 16:54:14 +0100
Message-ID: <[e-mail]>
Date: Wed, 05 Oct 2005 16:54:14 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Michael Haardt wrote:

>>Kjetil, can I ask you to add your example how to work-around this issue 
>>to the "variables" draft.
>>After that I will tell Scott that the document is ready for IESG.
>>    
>>
>
>Stop! :)
>
>There is still the yet unanswered question if leading or trailing white
>space on the right side is an error, as it could never be matched by
>any argument on the left side and is likely a mistake.
>  
>
It is a generic problem with the relational extension, so I don't think 
we need to address it in the variables draft.

Besides, the right hand side of a string test can contain variables. So 
I don't think it is a good idea to make leading/trailing whitespaces in 
the rightmost parameter a runtime error.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95Eopr2047146; Wed, 5 Oct 2005 07:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95EopM0047145; Wed, 5 Oct 2005 07:50:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95Eoo4Z047135 for <[e-mail]>; Wed, 5 Oct 2005 07:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1ENAbZ-0006w1-0E for [e-mail]; Wed, 05 Oct 2005 16:50:49 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ENAbY-0001YP-TR for [e-mail]; Wed, 05 Oct 2005 16:50:48 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1ENAbX-0007fF-93 for [e-mail]; Wed, 05 Oct 2005 16:50:47 +0200
Date: Wed, 5 Oct 2005 16:50:47 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 05, 2005 at 04:11:40PM +0200, Kjetil Torgrim Homme wrote:
> On Wed, 2005-10-05 at 14:26 +0200, Michael Haardt wrote:
> > There is still the yet unanswered question if leading or trailing white
> > space on the right side is an error, as it could never be matched by
> > any argument on the left side and is likely a mistake.
> 
> you're assuming only "eq" or "ne".  for "lt" the trailing whitespace
> will be significant.

Yes, and very confusing so, given X-field: a

if header :value "gt" :comparator ["x-field"] ["a "]

the test is true.  But I agree it may be desired for anything but "eq"
and "ne", so I suggest the following example:

  require "relational";
  if header :value "eq" "X-field" "trailing space " {
    # the above test never succeeds, because trailing spaces are
    # removed from the left side, see section 3.1.  Use :is
    # instead.
  }

That should illustrate the problem.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95EC6Wq042182; Wed, 5 Oct 2005 07:12:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95EC6oV042181; Wed, 5 Oct 2005 07:12:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95EC5e3042172 for <[e-mail]>; Wed, 5 Oct 2005 07:12:06 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1ENA02-0002b8-8w; Wed, 05 Oct 2005 16:12:02 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EN9zs-0001rX-9z; Wed, 05 Oct 2005 16:11:52 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 05 Oct 2005 16:11:40 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.717, required 12, autolearn=disabled, AWL 1.10, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-05 at 14:26 +0200, Michael Haardt wrote:
> There is still the yet unanswered question if leading or trailing white
> space on the right side is an error, as it could never be matched by
> any argument on the left side and is likely a mistake.

you're assuming only "eq" or "ne".  for "lt" the trailing whitespace
will be significant.  also, there are many other tests which will never
match, e.g.

   if address :is "From" "[e-mail]"

while some implementation may choose to look for and report such errors
(during upload), I don't think we need to get into details of this sort.

thanks for the note, though, because the text I just suggested for
variables is wrong!  here's a fixed version:


   Note: The "relational" extension also adds a match type called
   ":value".  This match type strips leading and trailing whitespace in
   the source string (or string list) prior to comparison.  If it is
   desired to make whitespace significant, this can be accomplished by
   prefixing and suffixing every value with an arbitrary non-whitespace
   character.

   Example:
      require "relational";
      set "empty" "";
      set "spaces" "      ";
      if string :value "eq" "${spaces}" "${empty}" {
          # the above test succeeds
      }
      if string :value "ne" "X${spaces}X" "X${empty}X" {
          # the above test succeeds
      }


-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95Dp88A039956; Wed, 5 Oct 2005 06:51:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95Dp8dk039955; Wed, 5 Oct 2005 06:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95Dp6lc039938 for <[e-mail]>; Wed, 5 Oct 2005 06:51:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EN9fj-00076X-5s; Wed, 05 Oct 2005 15:51:03 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EN9ff-0002Hy-JZ; Wed, 05 Oct 2005 15:50:59 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Wed, 05 Oct 2005 15:50:42 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.695, required 12, autolearn=disabled, AWL 1.12, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Wed, 2005-10-05 at 12:10 +0100, Alexey Melnikov wrote:
> Kjetil, can I ask you to add your example how to work-around this issue 
> to the "variables" draft.

I added this text:

   Note: The "relational" extension also adds a match type called
   ":value".  This match type strips leading and trailing whitespace in
   both values before comparing them.  If it is desired to make
   whitespace significant in the variable comparison, this can be
   accomplished by prefixing and suffixing both values with any non-
   whitespace character.

   Example:
      require "relational";
      set "empty" "";
      set "spaces" "      ";
      if string :value "eq" "${empty}" "${spaces}" {
          # the above test succeeds
      }
      if string :value "ne" "X${empty}X" "X${spaces}X" {
          # the above test succeeds
      }

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95CQkER029877; Wed, 5 Oct 2005 05:26:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95CQk0T029876; Wed, 5 Oct 2005 05:26:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95CQjtZ029867 for <[e-mail]>; Wed, 5 Oct 2005 05:26:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EN8M8-0004E2-4d for [e-mail]; Wed, 05 Oct 2005 14:26:44 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EN8M8-0001ru-3G for [e-mail]; Wed, 05 Oct 2005 14:26:44 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EN8M7-0007LD-Pe for [e-mail]; Wed, 05 Oct 2005 14:26:43 +0200
Date: Wed, 5 Oct 2005 14:26:43 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Wed, Oct 05, 2005 at 12:10:18PM +0100, Alexey Melnikov wrote:
> 
> Kjetil Torgrim Homme wrote:
> >we would need to come up with a more precise name for the match-type.
> >
> > if envelope :all :full "lt" "from" "[e-mail]" ...
> >
> >what is :all and what is :full?  two alternative names are ":verbatim"
> >and ":compare".

Sounds much better indeed.

> >adding a match-type means we would need a new name for the extension, or
> >perhaps a separate document for it.
> >
> Right. If anybody want to pursue that that will be fine with me.

Now that we do have a route to extend relational, should the need
ever arise in reality, plus a workaround that looks like it suffices,
I guess indeed you are right:

> It seems that the consensus is to keep the current behavior.

I agree.

> Kjetil, can I ask you to add your example how to work-around this issue 
> to the "variables" draft.
> After that I will tell Scott that the document is ready for IESG.

Stop! :)

There is still the yet unanswered question if leading or trailing white
space on the right side is an error, as it could never be matched by
any argument on the left side and is likely a mistake.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95BAU0P022833; Wed, 5 Oct 2005 04:10:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95BAUNC022832; Wed, 5 Oct 2005 04:10:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j95BARkR022825 for <[e-mail]>; Wed, 5 Oct 2005 04:10:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 5 Oct 2005 12:10:18 +0100
Message-ID: <[e-mail]>
Date: Wed, 05 Oct 2005 12:10:18 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>On Tue, 2005-10-04 at 15:24 +0200, Michael Haardt wrote:
>  
>
>>The ease of a new option like ":full" for keeping white space makes me
>>think "bloat", but unfortunately it does add what we ask for without
>>breaking anything.
>>    
>>
>
>we would need to come up with a more precise name for the match-type.
>
>  if envelope :all :full "lt" "from" "[e-mail]" ...
>
>what is :all and what is :full?  two alternative names are ":verbatim"
>and ":compare".
>
>adding a match-type means we would need a new name for the extension, or
>perhaps a separate document for it.
>
Right. If anybody want to pursue that that will be fine with me.

>I'm not sure it's worthwhile, as
>there is a known workaround for the stripping in the variables case
>(prefix both values with non-space) and in the header case I doubt any
>script will care.
>  
>
It seems that the consensus is to keep the current behavior.

Kjetil, can I ask you to add your example how to work-around this issue 
to the "variables" draft.
After that I will tell Scott that the document is ready for IESG.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94Ecvuq089406; Tue, 4 Oct 2005 07:38:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j94Ecv1I089405; Tue, 4 Oct 2005 07:38:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94Ecupt089395 for <[e-mail]>; Tue, 4 Oct 2005 07:38:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EMnwS-0005wb-24; Tue, 04 Oct 2005 16:38:52 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EMnw1-0000Sf-5D; Tue, 04 Oct 2005 16:38:25 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 04 Oct 2005 16:38:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.764, required 12, autolearn=disabled, AWL 1.05, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Tue, 2005-10-04 at 15:24 +0200, Michael Haardt wrote:
> The ease of a new option like ":full" for keeping white space makes me
> think "bloat", but unfortunately it does add what we ask for without
> breaking anything.

we would need to come up with a more precise name for the match-type.

  if envelope :all :full "lt" "from" "[e-mail]" ...

what is :all and what is :full?  two alternative names are ":verbatim"
and ":compare".

adding a match-type means we would need a new name for the extension, or
perhaps a separate document for it.  I'm not sure it's worthwhile, as
there is a known workaround for the stripping in the variables case
(prefix both values with non-space) and in the header case I doubt any
script will care.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94DOqAp080598; Tue, 4 Oct 2005 06:24:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j94DOqkK080597; Tue, 4 Oct 2005 06:24:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94DOp85080588 for <[e-mail]>; Tue, 4 Oct 2005 06:24:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EMmmo-00072v-Bx for [e-mail]; Tue, 04 Oct 2005 15:24:50 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EMmmo-0002aR-5h for [e-mail]; Tue, 04 Oct 2005 15:24:50 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EMmml-000543-Rr for [e-mail]; Tue, 04 Oct 2005 15:24:47 +0200
Date: Tue, 4 Oct 2005 15:24:47 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Mon, Oct 03, 2005 at 12:17:39PM +0200, Kjetil Torgrim Homme wrote:
> I do not particularily like the stripping, and ideally I think [ACAP]
> should have specified that i;ascii-numeric ignores leading whitespace.
> one alternative way back then would have been to register a new
> comparator which handles true numbers (ie. negative numbers and possibly
> even decimals) where leading whitespace is disregarded.

I agree that a new comparator and relational keeping white space would
be best, but I am afraid we are a minority on that issue.

The ease of a new option like ":full" for keeping white space makes me
think "bloat", but unfortunately it does add what we ask for without
breaking anything.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94DI4Pe079835; Tue, 4 Oct 2005 06:18:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j94DI4wf079834; Tue, 4 Oct 2005 06:18:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94DI3KB079825 for <[e-mail]>; Tue, 4 Oct 2005 06:18:03 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1EMmgD-0006BW-W0 for [e-mail]; Tue, 04 Oct 2005 15:18:01 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EMmgD-0000P0-US for [e-mail]; Tue, 04 Oct 2005 15:18:01 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EMmgB-00053D-JW for [e-mail]; Tue, 04 Oct 2005 15:17:59 +0200
Date: Tue, 4 Oct 2005 15:17:59 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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>

On Sun, Oct 02, 2005 at 10:01:03PM +0100, Alexey Melnikov wrote:
> >and syntactically checking the URL, generating an error on bad syntax.
> >
> I am fine with this part. I've added to 3.1:
> 
>    If the :method tag contains a supported URI schema, then the URI MUST
>    be checked for validity. An invalid URI syntax or an unsupported URI
>    extension MUST cause an error.

I suggest "syntactic validity" instead of "validity" and I would add

"Semantic errors MAY cause an error".

Foreign phone numbers are syntactically fine, but may not be allowed as
SMS targets by a site.  I think such a configuration should be allowed
to generate an error.  Most sites can not check if a phone number exists,
thus being unable to generate an error.  Hence MAY.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93HoaXk048798; Mon, 3 Oct 2005 10:50:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93Hoavb048796; Mon, 3 Oct 2005 10:50:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93HoZeB048788 for <[e-mail]>; Mon, 3 Oct 2005 10:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 3 Oct 2005 10:50:34 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1128361833; h=Date: 	 From:Subject:MIME-version:Content-type; b=Gmo0TWDxs543cb92XZ8Mtem+8 Vxd9s2SCCeADszx0/IfP4058/bnI8Ft1/6mv4dyhOR6ImpU6U+PzFAYJDUZKA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 03 Oct 2005 10:50:31 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 03 Oct 2005 10:46:25 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
In-reply-to: "Your message dated Mon, 03 Oct 2005 12:17:39 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> (looks like Alexey hit the "reply" button rather than "reply all".)

> On Sun, 2005-10-02 at 21:18 +0100, Alexey Melnikov wrote:
> > Kjetil Torgrim Homme wrote:
> > >On Tue, 2005-09-27 at 13:31 -0700, Ned Freed wrote:
> > >>I'm in favor of the behavior being consistent across all tests. If it isn't
> > >>we now hove to specify this obscure bit of behavior for every future
> > >>extension that introduces a test. Not good IMO.
> > >
> > >I agree.
> >
> > I agree with Ned's statement, however this doesn't answer my question:
> > do you want to always strip leading/trailing spaces for all tests or not?

> I do not particularily like the stripping, and ideally I think [ACAP]
> should have specified that i;ascii-numeric ignores leading whitespace.
> one alternative way back then would have been to register a new
> comparator which handles true numbers (ie. negative numbers and possibly
> even decimals) where leading whitespace is disregarded.

> however, can we change [RELATIONAL] in such a backwards compatibility
> breaking manner?

I see it as a question of which implementations do we break, and since there is
some chance that others have implemented these specifications in places we've
never heard of the bias needs to be towards keeping the status quo.

The reports I saw seemed to indicate that most implementations followed the old
specification in this regard. Our didn't, but it wasn't hard to change it to
comply. I also note that we implemented part of this but not all, so either way
this goes we'll need to change things.

My position is therefore that we should keep things the way they are. This
isn't the most convenient answer for our implementation, but given the
information we have available I think it is right one.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93FnL1n009660; Mon, 3 Oct 2005 08:49:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93FnLLf009659; Mon, 3 Oct 2005 08:49:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93FnKN7009639 for <[e-mail]>; Mon, 3 Oct 2005 08:49:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.132] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 3 Oct 2005 16:49:12 +0100
Message-ID: <[e-mail]>
Date: Mon, 03 Oct 2005 16:49:13 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: scoping and variables yet again
References: <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Kjetil Torgrim Homme wrote:

>okay, I suggest:
>
>        Variables are only visible to the currently running script.
>        Note: Future extensions may provide different scoping rules for
>        variables.
>
>by omitting the middle sentence, we avoid getting into dangling
>definitions (what's a "file"), and we also don't rule out the
>possibility of a block local scope.
>  
>
Ok, sounds like a reasonable compromise.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93FkbWf008749; Mon, 3 Oct 2005 08:46:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93Fkb6V008747; Mon, 3 Oct 2005 08:46:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93FkarT008721 for <[e-mail]>; Mon, 3 Oct 2005 08:46:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EMSWO-0007lw-Oa; Mon, 03 Oct 2005 17:46:32 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EMSWF-0003nI-O1; Mon, 03 Oct 2005 17:46:23 +0200
Subject: Re: scoping and variables yet again
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 03 Oct 2005 17:46:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.659, required 12, autolearn=disabled, AWL 1.15, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

On Mon, 2005-09-26 at 18:20 +0100, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >my suggestion is (text A), a complete reversal of behaviour:
> >
> >    Variables are only visible to the currently running script.
> >
> >the possibility of a different extension allowing a different scope is
> >implicit -- everything not forbidden can be overridden :-).  [...]
> >
> >Aaron Stone's suggestion is similar in effect, I think (text B):
> >
> >        All variables have global scope within a script. Future
> >        specifications may allow for a script to be composed of more
> >        than one file [part?], or for running more than one script per
> >        message [delivery?]. Such specifications may provide for
> >        different variable scoping rules.
> >
> >it attempts to be more explicit, but I think it muddies more than it
> >clarifies, to be honest.
>
> How about replacing the first sentence of B with your proposal A.
> 
> The rest of the paragraph is trying to say that there would be other 
> specification with different scoping rules, or additional operators that 
> can declare a variable global for other scripts/imported from another 
> script.

okay, I suggest:

        Variables are only visible to the currently running script.
        Note: Future extensions may provide different scoping rules for
        variables.

by omitting the middle sentence, we avoid getting into dangling
definitions (what's a "file"), and we also don't rule out the
possibility of a block local scope.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93CIrqq064140; Mon, 3 Oct 2005 05:18:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93CIrQj064139; Mon, 3 Oct 2005 05:18:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93CIqG8064132 for <[e-mail]>; Mon, 3 Oct 2005 05:18:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.132] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 3 Oct 2005 13:18:51 +0100
Message-ID: <[e-mail]>
Date: Mon, 03 Oct 2005 13:18:51 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Philip Guenther wrote:

>The two sample implementations of "addflag" should be next to each
>other.
>
>
>The sample "removeflag" implementation in section 6 is incorrect, as it
>will only remove a single occurence of the given flag.  (Even if
>"addflag" performs duplicate elimination, "removeflag" must still handle
>multiple occurences as the user may have altered the variable directly
>with "set".)
>  
>
After talking to Philip I would like to suggest to remove this section. 
Would anybody be upset with this?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93AI3E2055839; Mon, 3 Oct 2005 03:18:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93AI3PZ055838; Mon, 3 Oct 2005 03:18:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93AI2Sf055830 for <[e-mail]>; Mon, 3 Oct 2005 03:18:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EMNOO-0001Y2-Dt; Mon, 03 Oct 2005 12:17:56 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EMNOJ-0004bj-3b; Mon, 03 Oct 2005 12:17:51 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Mon, 03 Oct 2005 12:17:39 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.785, required 12, autolearn=disabled, AWL 1.03, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

(looks like Alexey hit the "reply" button rather than "reply all".)

On Sun, 2005-10-02 at 21:18 +0100, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >On Tue, 2005-09-27 at 13:31 -0700, Ned Freed wrote:
> >>I'm in favor of the behavior being consistent across all tests. If it isn't
> >>we now hove to specify this obscure bit of behavior for every future
> >>extension that introduces a test. Not good IMO.
> >
> >I agree.
>
> I agree with Ned's statement, however this doesn't answer my question: 
> do you want to always strip leading/trailing spaces for all tests or not?

I do not particularily like the stripping, and ideally I think [ACAP]
should have specified that i;ascii-numeric ignores leading whitespace.
one alternative way back then would have been to register a new
comparator which handles true numbers (ie. negative numbers and possibly
even decimals) where leading whitespace is disregarded.

however, can we change [RELATIONAL] in such a backwards compatibility
breaking manner?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j939tC8x053443; Mon, 3 Oct 2005 02:55:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j939tCVl053442; Mon, 3 Oct 2005 02:55:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j939tAxE053436 for <[e-mail]>; Mon, 3 Oct 2005 02:55:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 3 Oct 2005 10:44:38 +0100
Message-ID: <[e-mail]>
Date: Sun, 02 Oct 2005 22:01:03 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
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>

Michael Haardt wrote:

>On Tue, Sep 27, 2005 at 12:10:22PM +0100, Nigel Swinson wrote:
>  
>
>>    This document does not dictate the notification method used.
>>    Examples of possible notification methods are Zephyr and Jabber. The
>>-    method shall be site-defined.
>>+    available methods shall be site-defined.
>>
>>Which makes me wonder if each desired "method" should really be available via a require command?
>>    
>>
>
>I prefer a require commend for each method
>
I don't want to require a "require" statement for each URI schema. An 
URI can be fetched using a test from an external server (e.g. it can be 
an LDAP attribute value ;-)), in which case the script might not know 
all URI schemas in advance.

>and syntactically checking the URL, generating an error on bad syntax.
>
I am fine with this part. I've added to 3.1:

    If the :method tag contains a supported URI schema, then the URI MUST
    be checked for validity. An invalid URI syntax or an unsupported URI
    extension MUST cause an error.

Is this what you want?

>  And I would go as far as
>allowing semantic errors to cause errors on behalf of the implementation.
>  
>
>I ran various SMS gateways over the years and if there is one common
>problem, it is people embedding letters and all kinds of special
>characters in phone numbers, like @ and 8-bit characters, or doubling
>the number or the area prefix which yields way too long numbers.
>Simply dropping those numbers results in complaints why important SMS
>were not sent.  At one time I had almost 10% bad numbers and I am sick
>of complaints.
>  
>