Re: Generalizing subaddress

[Aaron Stone <[e-mail]>]

On Wed, 2006-03-29 at 18:35 -0800, Alexey Melnikov wrote:
> Dave Cridland wrote:
> > On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
[snip]
> > Perhaps what's actually needed is some kind of informational document 
> > describing various mechanisms that exist for subaddressing and similar 
> > local-part "encodings", and then using the subaddress Sieve extension 
> > to access those encodings.
> 
> Previous attempts to do this have failed (partially due to the help of 
> DJB). I think Chris had a draft on this.
> 
> So I remain skeptical if the new effort is going to be more successful.

I first became aware of subaddressing in a bug posted to the DBMail bug
tracker by a user who wanted username+mailbox addressing to be delivered
to the right mailbox. It turned out to require a fairly invasive set of
changes to the way we were looking up valid user accounts. Getting the
mailbox spec passed along the delivery chain was less difficult.

The real issue that I see here is that the mail delivery agent has to
make a decision about whether or not an address refers to a user on the
system -- parsing the address as needed to find the local user account
-- and then the Sieve engine presents the parsed address to the script.

In the case of DBMail and libSieve, only the verbatim address is passed;
the two code bases happen to perform the same decoding. What we're
looking at, then, is a de-facto standard that both codebases adhere to.
If either side of that interface changes its decoding pattern, then it
all breaks down. If a user posts a patch to the DBMail bug tracker
providing support for some other subaddress format, then I would have to
put it on hold, saying, "This can't go in until I've rewritten the patch
for libSieve, otherwise you won't be able to use Sieve with this new
subaddress format."

Implicit in the Sieve subaddress draft is that there is a format of
either: userSEPdetail@domain or detailSEPuser@domain. In database terms,
we would be violating "first normal form" if :user were further
internally formatted and required a regex to parse. It would also mean
explaining mail-system-internals to the script authors. Basically,
exactly what we're trying to prevent with this spec.

As I understand the debate to date, there are two questions holding
things up: more subaddress parts, and more complex, possibly nested,
encodings. I think I've seen the two-part-subaddress but
double-encoded-detail dismissed as being something the implementation
can handle already -- like username+=XYZ-BASE64-123=@domain. That's easy
to resolve, but probably should be treated more directly in the RFC.

Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:

1.  There is always a "user" part, which refers to an account
    in the email system.
2.  There might be a "detail" part.
3.  There might be a couple of detail parts.

We currently accept and act on facts 1 and 2. The proposals on 3 all
seem to have suggested adding more names; :detail, :mailbox, :voicemail,
whatever. The names are inherently specific to some interpretation of
the fields in the subaddress coding, thereby creating a standard, and
then putting us in need of writing that standard, which nobody wants to
do because there are so many systems already out there. How about this:

3A. :detail0 is an alias for :detail. :detail1, :detail2 ... :detailn
    refer to other parts of the subaddress; implementation defined,
    with common uses documented in an informal manner, just enough to
    give new implementors an idea of what's already out there.


Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UJPjHQ025968; Thu, 30 Mar 2006 12:25:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UJPjuE025967; Thu, 30 Mar 2006 12:25:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UJPivX025950 for <[e-mail]>; Thu, 30 Mar 2006 12:25:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.14] (dsl3-63-249-106-4.cruzio.com [63.249.106.4]) by mail.serendipity.cx (Postfix) with ESMTP id 8922F6017D9A; Thu, 30 Mar 2006 11:25:40 -0800 (PST)
Subject: Re: Generalizing subaddress
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 30 Mar 2006 11:26:04 -0800
Message-Id: <1143746764.22334.58.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
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>

On Wed, 2006-03-29 at 18:35 -0800, Alexey Melnikov wrote:
> Dave Cridland wrote:
> > On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
[snip]
> > Perhaps what's actually needed is some kind of informational document 
> > describing various mechanisms that exist for subaddressing and similar 
> > local-part "encodings", and then using the subaddress Sieve extension 
> > to access those encodings.
> 
> Previous attempts to do this have failed (partially due to the help of 
> DJB). I think Chris had a draft on this.
> 
> So I remain skeptical if the new effort is going to be more successful.

I first became aware of subaddressing in a bug posted to the DBMail bug
tracker by a user who wanted username+mailbox addressing to be delivered
to the right mailbox. It turned out to require a fairly invasive set of
changes to the way we were looking up valid user accounts. Getting the
mailbox spec passed along the delivery chain was less difficult.

The real issue that I see here is that the mail delivery agent has to
make a decision about whether or not an address refers to a user on the
system -- parsing the address as needed to find the local user account
-- and then the Sieve engine presents the parsed address to the script.

In the case of DBMail and libSieve, only the verbatim address is passed;
the two code bases happen to perform the same decoding. What we're
looking at, then, is a de-facto standard that both codebases adhere to.
If either side of that interface changes its decoding pattern, then it
all breaks down. If a user posts a patch to the DBMail bug tracker
providing support for some other subaddress format, then I would have to
put it on hold, saying, "This can't go in until I've rewritten the patch
for libSieve, otherwise you won't be able to use Sieve with this new
subaddress format."

Implicit in the Sieve subaddress draft is that there is a format of
either: userSEPdetail@domain or detailSEPuser@domain. In database terms,
we would be violating "first normal form" if :user were further
internally formatted and required a regex to parse. It would also mean
explaining mail-system-internals to the script authors. Basically,
exactly what we're trying to prevent with this spec.

As I understand the debate to date, there are two questions holding
things up: more subaddress parts, and more complex, possibly nested,
encodings. I think I've seen the two-part-subaddress but
double-encoded-detail dismissed as being something the implementation
can handle already -- like username+=XYZ-BASE64-123=@domain. That's easy
to resolve, but probably should be treated more directly in the RFC.

Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:

1.  There is always a "user" part, which refers to an account
    in the email system.
2.  There might be a "detail" part.
3.  There might be a couple of detail parts.

We currently accept and act on facts 1 and 2. The proposals on 3 all
seem to have suggested adding more names; :detail, :mailbox, :voicemail,
whatever. The names are inherently specific to some interpretation of
the fields in the subaddress coding, thereby creating a standard, and
then putting us in need of writing that standard, which nobody wants to
do because there are so many systems already out there. How about this:

3A. :detail0 is an alias for :detail. :detail1, :detail2 ... :detailn
    refer to other parts of the subaddress; implementation defined,
    with common uses documented in an informal manner, just enough to
    give new implementors an idea of what's already out there.


Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2U9tDsF097726; Thu, 30 Mar 2006 02:55:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2U9tDvb097725; Thu, 30 Mar 2006 02:55:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2U9t78o097703 for <[e-mail]>; Thu, 30 Mar 2006 02:55:09 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 30 Mar 2006 10:54:48 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Mar 2006 18:35:21 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: [e-mail]
Subject: Re: Generalizing subaddress
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>

Dave Cridland wrote:

> On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
>
>> I was tasked at Tuesday's Sieve WG meeting with trying to make the 
>> language in the subaddress draft even more general than it currently 
>> is, but as Philip noted in another thread, doing so makes it very 
>> difficult to describe when :detail is present/empty/not present.  I 
>> have not found a way to describe these states without relying on some 
>> type of 'delimiter' or 'separator'.
>>
>> Consider this a plea for some suggested text.
>
> I think much of Ken's problem here is that he's trying to build a 
> standard method for doing something with unstandardized local part 
> formats.
>
> Perhaps what's actually needed is some kind of informational document 
> describing various mechanisms that exist for subaddressing and similar 
> local-part "encodings", and then using the subaddress Sieve extension 
> to access those encodings.

Previous attempts to do this have failed (partially due to the help of 
DJB). I think Chris had a draft on this.

So I remain skeptical if the new effort is going to be more successful.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2U9tAXk097723; Thu, 30 Mar 2006 02:55:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2U9tAbs097722; Thu, 30 Mar 2006 02:55:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2U9t78n097703 for <[e-mail]>; Thu, 30 Mar 2006 02:55:08 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 30 Mar 2006 10:54:46 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Mar 2006 18:32:56 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: Generalizing subaddress
References: <[e-mail]> <[e-mail]> <sQ00HAs+c8OKR/[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>

Dave Cridland wrote:

>> How about just specifying that
>> a) this extension is limited to subaddresses which use separators,
>> b) a future extension may lift that restriction, and
>> c) the separator may consist of one character, of several characters 
>> or even of a zero-width boundary such as e.g. "letter on one side, 
>> nonletter on the other"?
>
> I'm mildly concerned you're infringing on (9) and (10), but if we're 
> going to dump any idea of addressing subaddresses further [if you can 
> follow that] then I'd like to canvas implementors on what they think a 
> subaddress is, whether it sometimes/usually fits this description, and 
> whether we might as well chop it further. (Say, by insisting on a '+' 
> postfix

Existing implementation already use '-' or '--'.
This was already discussed on the mailing list, so lets not revisit this 
decision.

> ).





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S7MvXZ047536; Tue, 28 Mar 2006 00:22:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S7MvKf047535; Tue, 28 Mar 2006 00:22:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S7MtOv047529 for <[e-mail]>; Tue, 28 Mar 2006 00:22:56 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FO8XU-0006eg-5R; Tue, 28 Mar 2006 07:22:52 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 5C20B498003; Tue, 28 Mar 2006 08:27:16 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03719-07; Tue, 28 Mar 2006 08:27:04 +0100 (BST)
Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:bddf:5dd:5b98:dadb]) by turner.dave.cridland.net (Postfix) with ESMTP id 70B08498002; Tue, 28 Mar 2006 08:27:02 +0100 (BST)
Date: Tue, 28 Mar 2006 08:20:23 +0100
Subject: Re: document status: 3028bis, body, editheader
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <2304.1143530424.288000@JOHN>
From: Dave Cridland <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: <[e-mail]>, Ned Freed <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2S7MuOv047530
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 Mar 28 03:07:20 2006, Kjetil Torgrim Homme wrote:
> On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:
> 
> > > I thought Dave Cridland's suggestion to specify matching 
> behaviour in
> > > the comparator itself was intriguing:
> > >
> > > http://permalink.gmane.org/gmane.ietf.mta-filters/2689
> > >
> > > unfortunately, [draft-newman-i18n-comparator-08] says «the 
> equality test
> > > MUST be reflexive, symmetric and transitive», so "EQUAL" can't 
> be used.
> > > I must admit I don't quite understand how :matches and :regex 
> work with
> > > comparators, though.
> > > > I think of it this way: A comparator has as one of it's 
> components a
> > normalization operation. Pull that operation out, apply it, and 
> then
> > perform the glob or regex operation on the result. Note that the
> > output of the normalization is best seen as a series of 
> nonnegative
> > integers or someting similar, not octets or characters.
> 
> 
> thanks.
> 
> so you split your match pattern into constant strings without the
> wildcards, send each to the comparator which returns a list of 
> start and
> end points for each matched constant string, and then see if you can
> find a sequence of (start, end) for each constant string where the
> intervals between the constant strings match the wildcards.  *phew*
> 
> that will work for :matches (although I doubt anyone will actually
> implement it that way -- so the pluggable comparator idea goes out 
> the
> window), but not for :regex.  unless I'm missing something again :-)
> 
> 
I think we have to document reality here. The reality seems to be 
that not only do comparators have a normalization operation, but they 
also have a match operation. I *suspect* that the matching function 
has '?', '%', and '*' wildcards, although only two are used in Sieve.

I'd like to float the notion that somebody writes text suitable to 
document this at the comparator level.

We'd want to define this such that existing usage is captured, and 
sensible definitions for i;basic* apply, such that '?' wildcard 
behaviour works as expected.

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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S2hprC035247; Mon, 27 Mar 2006 19:43:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S2hpr9035246; Mon, 27 Mar 2006 19:43:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S2hnQX035240 for <[e-mail]>; Mon, 27 Mar 2006 19:43:50 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1FO4BO-0006z1-49; Tue, 28 Mar 2006 04:43:46 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FO4BF-0001oj-KR; Tue, 28 Mar 2006 04:43:37 +0200
Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="=-rubO0Oqsvm3DZucUGjGc"
Date: Tue, 28 Mar 2006 04:07:20 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.192, required 12, autolearn=disabled, AWL -0.25, HTML_30_40 0.06, HTML_MESSAGE 0.00, 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>

--=-rubO0Oqsvm3DZucUGjGc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:

> > I thought Dave Cridland's suggestion to specify matching behaviour in
> > the comparator itself was intriguing:
> >
> > http://permalink.gmane.org/gmane.ietf.mta-filters/2689
> >
> > unfortunately, [draft-newman-i18n-comparator-08] says =ABthe equality t=
est
> > MUST be reflexive, symmetric and transitive=BB, so "EQUAL" can't be use=
d.
> > I must admit I don't quite understand how :matches and :regex work with
> > comparators, though.
>=20
>=20
> I think of it this way: A comparator has as one of it's components a
> normalization operation. Pull that operation out, apply it, and then
> perform the glob or regex operation on the result. Note that the
> output of the normalization is best seen as a series of nonnegative
> integers or someting similar, not octets or characters.


thanks.

so you split your match pattern into constant strings without the
wildcards, send each to the comparator which returns a list of start and
end points for each matched constant string, and then see if you can
find a sequence of (start, end) for each constant string where the
intervals between the constant strings match the wildcards.  *phew*

that will work for :matches (although I doubt anyone will actually
implement it that way -- so the pluggable comparator idea goes out the
window), but not for :regex.  unless I'm missing something again :-)


> > another possibility is to have a capability which adds an action which
> > changes the default comparator to reduce the verbosity.
>=20
>=20
> It makes scripts a bit shorter, but at the expense of having something
> with far-reaching impact specified at the top and not where the impact
> is felt. I'm far from convinced this is a good tradeoff.


what do you mean by impact?  server load?


> > another possibility is to allow the wildcard comparator, so
> > that :comparator "*" =AB[selects] the collation with the broadest scope
> > (preferably international scope), the most recent table versions and th=
e
> > greatest number of supported operations.=BB  (the comparators the serve=
r
> > chooses from would have to be "require"d in advance, I think, although
> > =ABrequire "comparator-*"=BB is a possibility)
>=20
>=20
> I really don't like this - now you have scripts working in subtlely
> different ways in different places. This is big steps backwards, I
> think.


you can reduce the problem by not doing require on more comparators than
you need.  e.g., if you do

  require "comparator-i;basic;uca=3D3.1.1;uv=3D3.2";
  require "comparator-i;ascii-numeric";
  require "comparator-*";

it's quite obvious which comparator has the =ABbroadest international
scope=BB (just to make it clear, this is the wording about the behaviour
of "*" from [COLLATION]).


> > > And good luck using i;basic;uca=3D3.1.1;uv=3D3.2 to trap specific seq=
uences of
> > > illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> > > experience at least.
> >
> > this is impossible today, isn't it?
>=20
> It is done all the time and the base specification allows it, more or
> less.


well, that's in contention.


> > how do you specify the string to compare with?
>=20
>=20
> You just do it. Nothing in the current sieve specification says that
> it is an error to specify material that isn't valid utf-8.


8.1.     Lexical Tokens

   Sieve scripts are encoded in UTF-8.  The following assumes a valid
   UTF-8 encoding; special characters in Sieve scripts are all ASCII.

"are" is considered equivalent with a MUST, isn't it?


> (This is now prohibited by the ABNF in the revised base specification,
> and IMO this restriction needs to be removed for string constants.


I strongly disagree.  let's not make a charset soup on purpose.


> It is at a minimum in direct conflict with the vacation
> specification.)



not relevant, since vacation hasn't left draft status.



> > in any case, if you want to trap raw non-UTF8 in headers,
> > you should use i;octet.
>=20
>=20
> Agreed, but in practice scripts often don't specify this.


such scripts are broken and rely on undocumented behaviour IMO.



> >  but then again:
> >
> > 5.7.  Octet Collation
> >
> >    The i;octet (Section 9.5) collation is only usable with protocols
> >    based on octet-strings.  Clients and servers MUST NOT use i;octet
> >    with other protocols.
> >
> > which would disqualify the use of i;octet with Sieve, since 3028bis say=
s:
> >
> >    The language is represented in UTF-8, as specified in [UTF-8].
>=20
>=20
> Represent doesn't mean things are restricted to UTF-8.


yes, this is fine.  the message can contain octet strings even if the
script itself can not.  sorry about the red herring.


> If it did it would be in direct conflict with later language in the
> same document, which quite specifically allows material in other
> charsets in strings.


what language are you thinking of?


> > the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
> > clear to me that a 3028bis can get the same exemption.
>=20
>=20
> It better or backwards compatibility goes down the toilet, which is
> not acceptable as far as I'm concerned.


how about implementations where "?" matches a Unicode character even for
the default comparator?  which implementation gets to define backwards
compatibility?


> > notice that
> > "represented in UTF-8" only means constant strings can't contain raw
> > octets which are illegal UTF-8 sequences.
>=20
>=20
> I disagree 100% that that is what it means. And since the
> specification later talks about putting non-UTF-8 material in constant
> strings in section 2.4.2.4, it seems it agrees with me.


it's not clear that 2.4.2.4 expects the Sieve implementation to decode
the embedded MIME document into raw octets.  I would expect the
opposite, that the MIME headers and encoded data supplied in the script
are copied verbatim.


> > which brings us back to the
> > discussion on character escapes from a year ago.
>=20
> > http://comments.gmane.org/gmane.ietf.mta-filters/2030
>=20
> > I'd like to suggest we implement (2), but with the extension defined in
> > the base spec.
>=20
>=20
> I have no problem with this and would like to see it happen,


I'm glad to hear it.  I guess I should submit text for consideration :-)


> Regardless of whether you write some sequence that's illegal in UTF-8
> directly as a series of octets in a string constant or indirectly
> using some sort of encoding, you're still presenting the sieve
> interpreter with text that isn't in utf-8 at some level.


the Sieve interpreter needs to handle non-UTF-8 already. that is, header
bodies which are encoded in an unknown charset must be handled as
octet-strings.

looking at the current draft, I think this excerpt from 2.7.2 needs a
little tweak:


   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
      greater than 127.


(this is unchanged since 3028).  I believe it should be allowed to
compare such strings using i;octet.  I don't have suitable replacement
text, though.


> Any attempt to enforce some sort of rule that nothing but utf-8 can be
> present is still going to fail. And any +Unnnn sort of scheme is
> inherently incapable of representing UTF-8 anyway.


well, yes, it represents a Unicode code point, not an octet sequence.
but as we have established, with the correct comparator, you can use "?"
to see that the *client visible* representation of Sieve strings is in
fact UTF-8.
--=20
Kjetil T.


--=-rubO0Oqsvm3DZucUGjGc
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.0">
</HEAD>
<BODY>
On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; I thought Dave Cridland's suggestion to specify matching behaviour in</FONT>
<FONT COLOR="#000000">&gt; the comparator itself was intriguing:</FONT>
&gt;
<FONT COLOR="#000000">&gt; <A HREF="http://permalink.gmane.org/gmane.ietf.mta-filters/2689">http://permalink.gmane.org/gmane.ietf.mta-filters/2689</A></FONT>
&gt;
<FONT COLOR="#000000">&gt; unfortunately, [draft-newman-i18n-comparator-08] says &#171;the equality test</FONT>
<FONT COLOR="#000000">&gt; MUST be reflexive, symmetric and transitive&#187;, so &quot;EQUAL&quot; can't be used.</FONT>
<FONT COLOR="#000000">&gt; I must admit I don't quite understand how :matches and :regex work with</FONT>
<FONT COLOR="#000000">&gt; comparators, though.</FONT>

</PRE>
    <FONT COLOR="#000000">I think of it this way: A comparator has as one of it's components a</FONT> <FONT COLOR="#000000">normalization operation. Pull that operation out, apply it, and then perform</FONT> <FONT COLOR="#000000">the glob or regex operation on the result. Note that the output of the</FONT> <FONT COLOR="#000000">normalization is best seen as a series of nonnegative integers or someting</FONT> <FONT COLOR="#000000">similar, not octets or characters.</FONT><BR>
</BLOCKQUOTE>
<BR>
thanks.<BR>
<BR>
so you split your match pattern into constant strings without the wildcards, send each to the comparator which returns a list of start and end points for each matched constant string, and then see if you can find a sequence of <TT>(start, end)</TT> for each constant string where the intervals between the constant strings match the wildcards.&nbsp; *phew*<BR>
<BR>
that will work for <TT>:matches</TT> (although I doubt anyone will actually implement it that way -- so the pluggable comparator idea goes out the window), but not for <TT>:regex.</TT>&nbsp; unless I'm missing something again :-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; another possibility is to have a capability which adds an action which</FONT>
<FONT COLOR="#000000">&gt; changes the default comparator to reduce the verbosity.</FONT>

</PRE>
    <FONT COLOR="#000000">It makes scripts a bit shorter, but at the expense of having something with</FONT> <FONT COLOR="#000000">far-reaching impact specified at the top and not where the impact is felt. I'm</FONT> <FONT COLOR="#000000">far from convinced this is a good tradeoff.</FONT><BR>
</BLOCKQUOTE>
<BR>
what do you mean by impact?&nbsp; server load?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; another possibility is to allow the wildcard comparator, so</FONT>
<FONT COLOR="#000000">&gt; that :comparator &quot;*&quot; &#171;[selects] the collation with the broadest scope</FONT>
<FONT COLOR="#000000">&gt; (preferably international scope), the most recent table versions and the</FONT>
<FONT COLOR="#000000">&gt; greatest number of supported operations.&#187;  (the comparators the server</FONT>
<FONT COLOR="#000000">&gt; chooses from would have to be &quot;require&quot;d in advance, I think, although</FONT>
<FONT COLOR="#000000">&gt; &#171;require &quot;comparator-*&quot;&#187; is a possibility)</FONT>
</PRE>
    <BR>
    <FONT COLOR="#000000">I really don't like this - now you have scripts working in subtlely different </FONT><FONT COLOR="#000000">ways in different places. This is big steps backwards, I think.</FONT><BR>
</BLOCKQUOTE>
<BR>
you can reduce the problem by not doing require on more comparators than you need.&nbsp; e.g., if you do<BR>
<BR>
<TT>&nbsp; require &quot;com</TT><TT><FONT COLOR="#000000">parator-i;basic;uca=3.1.1;uv=3.2&quot;;</FONT></TT><BR>
<TT>&nbsp; require &quot;comparator-i;ascii-numeric&quot;;</TT><BR>
<TT>&nbsp; require &quot;comparator-*&quot;;</TT><BR>
<BR>
it's quite obvious which comparator has the &#171;broadest international scope&#187; (just to make it clear, this is the wording about the behaviour of &quot;*&quot; from [COLLATION]).<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; &gt; And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of</FONT>
<FONT COLOR="#000000">&gt; &gt; illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my</FONT>
<FONT COLOR="#000000">&gt; &gt; experience at least.</FONT>
&gt;
<FONT COLOR="#000000">&gt; this is impossible today, isn't it?</FONT>
</PRE>
    <FONT COLOR="#000000">It is done all the time and the base specification allows it, more or less.</FONT><BR>
</BLOCKQUOTE>
<BR>
well, that's in contention.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; how do you specify the string to compare with?</FONT>
</PRE>
    <BR>
    <FONT COLOR="#000000">You just do it. Nothing in the current sieve specification says that it is an</FONT> <FONT COLOR="#000000">error to specify material that isn't valid utf-8.</FONT><BR>
</BLOCKQUOTE>
<BR>
<TT>8.1.&nbsp;&nbsp;&nbsp;&nbsp; Lexical Tokens</TT><BR>
<BR>
<TT>&nbsp;&nbsp; Sieve scripts are encoded in UTF-8.&nbsp; The following assumes a valid</TT><BR>
<TT>&nbsp;&nbsp; UTF-8 encoding; special characters in Sieve scripts are all ASCII.</TT><BR>
<BR>
&quot;are&quot; is considered equivalent with a MUST, isn't it?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">(This is now prohibited by</FONT> <FONT COLOR="#000000">the ABNF in the revised base specification, and IMO this restriction needs to</FONT> <FONT COLOR="#000000">be removed for string constants.</FONT><BR>
</BLOCKQUOTE>
<BR>
I strongly disagree.&nbsp; let's not make a charset soup on purpose.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">It is at a minimum in direct conflict with the</FONT> <FONT COLOR="#000000">vacation specification.)</FONT>
</BLOCKQUOTE>
<PRE>

</PRE>
not relevant, since vacation hasn't left draft status.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; in any case, if you want to trap raw non-UTF8 in headers,</FONT>
<FONT COLOR="#000000">&gt; you should use i;octet.</FONT>

</PRE>
    <FONT COLOR="#000000">Agreed, but in practice scripts often don't specify this.</FONT><BR>
</BLOCKQUOTE>
<BR>
such scripts are broken and rely on undocumented behaviour IMO.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt;  but then again:</FONT>
&gt;
<FONT COLOR="#000000">&gt; </FONT><FONT COLOR="#000000"><TT>5.7.&nbsp; Octet Collation</TT></FONT>
&gt;
<FONT COLOR="#000000"><TT>&gt;    The i;octet (Section 9.5) collation is only usable with protocols</TT></FONT>
<FONT COLOR="#000000"><TT>&gt;    based on octet-strings.  Clients and servers MUST NOT use i;octet</TT></FONT>
<FONT COLOR="#000000"><TT>&gt;&nbsp;&nbsp;&nbsp; with other protocols.</TT></FONT>
&gt;
<FONT COLOR="#000000">&gt; which would disqualify the use of i;octet with Sieve, since 3028bis says:</FONT>
&gt;
<FONT COLOR="#000000">&gt;&nbsp;&nbsp;&nbsp; The language is represented in UTF-8, as specified in [UTF-</FONT>8].

</PRE>
    <FONT COLOR="#000000">Represent doesn't mean things are restricted to UTF-8.</FONT><BR>
</BLOCKQUOTE>
<BR>
yes, this is fine.&nbsp; the message can contain octet strings even if the script itself can not.&nbsp; sorry about the red herring.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">If it did it would be in</FONT> <FONT COLOR="#000000">direct conflict with later language in the same document, which quite</FONT> <FONT COLOR="#000000">specifically allows material in other charsets in strings.</FONT><BR>
</BLOCKQUOTE>
<BR>
what language are you thinking of?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; the collation-draft exempts RFC 3028 from this &quot;MUST NOT&quot;, but it's not</FONT>
<FONT COLOR="#000000">&gt; clear to me that a 3028bis can get the same exemption.</FONT>

</PRE>
    <FONT COLOR="#000000">It better or backwards compatibility goes down the toilet, which is not</FONT> <FONT COLOR="#000000">acceptable as far as I'm concerned.</FONT><BR>
</BLOCKQUOTE>
<BR>
how about implementations where &quot;?&quot; matches a Unicode character even for the default comparator?&nbsp; which implementation gets to define backwards compatibility?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; notice that</FONT>
<FONT COLOR="#000000">&gt; &quot;represented in UTF-8&quot; only means constant strings can't contain raw</FONT>
<FONT COLOR="#000000">&gt; octets which are illegal UTF-8 sequences.</FONT>

</PRE>
    <FONT COLOR="#000000">I disagree 100% that that is what it means. And since the specification later</FONT> <FONT COLOR="#000000">talks about putting non-UTF-8 material in constant strings in section 2.4.2.4,</FONT> <FONT COLOR="#000000">it seems it agrees with me.</FONT><BR>
</BLOCKQUOTE>
<BR>
it's not clear that 2.4.2.4 expects the Sieve implementation to decode the embedded MIME document into raw octets.&nbsp; I would expect the opposite, that the MIME headers and encoded data supplied in the script are copied verbatim.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; which brings us back to the</FONT>
<FONT COLOR="#000000">&gt; discussion on character escapes from a year ago.</FONT>

<FONT COLOR="#000000">&gt; <A HREF="http://comments.gmane.org/gmane.ietf.mta-filters/2030">http://comments.gmane.org/gmane.ietf.mta-filters/2030</A></FONT>

<FONT COLOR="#000000">&gt; I'd like to suggest we implement (2), but with the extension defined in</FONT>
<FONT COLOR="#000000">&gt; the base spec.</FONT>

</PRE>
    <FONT COLOR="#000000">I have no problem with this and would like to see it happen,</FONT><BR>
</BLOCKQUOTE>
<BR>
I'm glad to hear it.&nbsp; I guess I should submit text for consideration :-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Regardless of whether you write some</FONT> <FONT COLOR="#000000">sequence that's illegal in UTF-8 directly as a series of octets in a string</FONT> <FONT COLOR="#000000">constant or indirectly using some sort of encoding, you're still presenting the</FONT> <FONT COLOR="#000000">sieve interpreter with text that isn't in utf-8 at some level.</FONT><BR>
</BLOCKQUOTE>
<BR>
the Sieve interpreter needs to handle non-UTF-8 already. that is, header bodies which are encoded in an unknown charset must be handled as octet-strings.<BR>
<BR>
looking at the current draft, I think this excerpt from 2.7.2 needs a little tweak:<BR>
<BR>
<PRE>
   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; greater than 127.

</PRE>
(this is unchanged since 3028).&nbsp; I believe it should be allowed to compare such strings using <TT>i;octet</TT>.&nbsp; I don't have suitable replacement text, though.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Any attempt to</FONT> <FONT COLOR="#000000">enforce some sort of rule that nothing but utf-8 can be present is still going</FONT> <FONT COLOR="#000000">to fail. And any +Unnnn sort of scheme is inherently incapable of representing</FONT> <FONT COLOR="#000000">UTF-8 anyway.</FONT><BR>
</BLOCKQUOTE>
<BR>
well, yes, it represents a Unicode code point, not an octet sequence.&nbsp; but as we have established, with the correct comparator, you can use &quot;<TT>?</TT>&quot; to see that the *<B>client visible*</B> representation of Sieve strings is in fact UTF-8.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Kjetil T.

</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-rubO0Oqsvm3DZucUGjGc--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S1mvNY032303; Mon, 27 Mar 2006 18:48:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S1mv4V032302; Mon, 27 Mar 2006 18:48:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S1muF1032296 for <[e-mail]>; Mon, 27 Mar 2006 18:48:56 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 27 Mar 2006 17:48:46 -0800 (PST)
Cc: Michael Haardt <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 27 Mar 2006 17:44:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Generalizing subaddress
In-reply-to: "Your message dated Tue, 28 Mar 2006 02:27:24 +0200" <[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, 2006-03-24 at 15:47 +0100, Michael Haardt wrote:
> > If the encoding of a detail depends on the target address, determining
> > if it contains no, an empty or a non-empty detail part depends on the
> > target address, too.  It can not be described in the subaddress extension.
> >
> > I suggest:
> >
> >    The ":detail" argument specifies the detail sub-part of the local-part
> >    of an address.  The encoding of the detail sub-part is dependent on
> >    the encompassing mail system and recipient address.  If the recipient
> >    address is not encoded to contain a detail part, the test evaluates
> >    to false.  An encoded empty detail information causes an empty key
> >    ("").

I suggest changing the last sentence to something like 'An encoded empty
detail sub-part will product the empty key value ("").'

> > Something sounds wrong there, but a native speaker can certainly fix it.

> sounds good to me, but I'm not a native speaker, either :-)  I assume
> you mean the "Note" following the paragraph should be removed, too.

> the introduction needs to be made less explicit, it says:

> .  Introduction

>    Subaddressing is the practice of augmenting (usually with a suffix)
>    the local-part of an [RFC2822] address with some "detail" information
>    to indicate that the message should be delivered to the mailbox
>    specified by the "detail" information.  A "separator character
>    sequence" (typically "+"), forms the boundary between the "user"
>    (original local-part) and "detail" sub-parts of the address, much
>    like the "@" character forms the boundary between the local-part and
>    domain.

> I suggest to change the last sentence:

>         One common way of encoding "detail" information is to add a
>         "separator character sequence", for instance "+", to form a
>         boundary between the "user" (original local-part) and "detail"
>         sub-parts [...]

> the examples are fine, but a more "esoteric" example would be nice.  I
> suggest BATV as an informative reference.  it only applies to bounce
> messages, of course (since a remote recipient can't decode it), but it's
> an example of an opaque encoding with information which could be
> presented to the user through this extension if the server administrator
> chooses to.

I have to say I'm not wild about using system-level examples in this
context. As I tried to point out at the meeting last week, the intent
behind this extension is to provide a means for users to extract subaddress
information from their addresses in a portable way. It isn't clear to me
it is appropriate to use this mechanism for BATV, or SRS, or anything
similar, so I'm hesitant to have examples of such usage.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S0RZXF028272; Mon, 27 Mar 2006 17:27:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S0RZ27028271; Mon, 27 Mar 2006 17:27:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S0RY42028264 for <[e-mail]>; Mon, 27 Mar 2006 17:27:35 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1FO23W-0001VE-TA; Tue, 28 Mar 2006 02:27:31 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FO23R-0006rD-B2; Tue, 28 Mar 2006 02:27:25 +0200
Subject: Re: Generalizing subaddress
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: Tue, 28 Mar 2006 02:27:24 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.19, required 12, autolearn=disabled, AWL -0.19, 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, 2006-03-24 at 15:47 +0100, Michael Haardt wrote:
> If the encoding of a detail depends on the target address, determining
> if it contains no, an empty or a non-empty detail part depends on the
> target address, too.  It can not be described in the subaddress extension.
> 
> I suggest:
> 
>    The ":detail" argument specifies the detail sub-part of the local-part
>    of an address.  The encoding of the detail sub-part is dependent on
>    the encompassing mail system and recipient address.  If the recipient
>    address is not encoded to contain a detail part, the test evaluates
>    to false.  An encoded empty detail information causes an empty key
>    ("").
> 
> Something sounds wrong there, but a native speaker can certainly fix it.

sounds good to me, but I'm not a native speaker, either :-)  I assume
you mean the "Note" following the paragraph should be removed, too.

the introduction needs to be made less explicit, it says:

.  Introduction

   Subaddressing is the practice of augmenting (usually with a suffix)
   the local-part of an [RFC2822] address with some "detail" information
   to indicate that the message should be delivered to the mailbox
   specified by the "detail" information.  A "separator character
   sequence" (typically "+"), forms the boundary between the "user"
   (original local-part) and "detail" sub-parts of the address, much
   like the "@" character forms the boundary between the local-part and
   domain.

I suggest to change the last sentence:

        One common way of encoding "detail" information is to add a
        "separator character sequence", for instance "+", to form a
        boundary between the "user" (original local-part) and "detail"
        sub-parts [...]

the examples are fine, but a more "esoteric" example would be nice.  I
suggest BATV as an informative reference.  it only applies to bounce
messages, of course (since a remote recipient can't decode it), but it's
an example of an opaque encoding with information which could be
presented to the user through this extension if the server administrator
chooses to.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S08gn1027202; Mon, 27 Mar 2006 17:08:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S08gVC027201; Mon, 27 Mar 2006 17:08:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S08e69027185 for <[e-mail]>; Mon, 27 Mar 2006 17:08:41 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1FO1lE-0005eY-N6; Tue, 28 Mar 2006 02:08:36 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FO1l8-0007gf-Tz; Tue, 28 Mar 2006 02:08:30 +0200
Subject: Re: Sieve mime loop issues list
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <003401c64f44$657bf230$9b42c050@nigelhome>
References: <[e-mail]> <[e-mail]> <003401c64f44$657bf230$9b42c050@nigelhome>
Content-Type: multipart/alternative; boundary="=-h7Ln7RcOAxUVddDOzd9t"
Date: Tue, 28 Mar 2006 02:08:29 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.214, required 12, autolearn=disabled, AWL -0.27, HTML_30_40 0.06, HTML_MESSAGE 0.00, 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>

--=-h7Ln7RcOAxUVddDOzd9t
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote:

> > > #1: Need to deal with nested for_every_part loops. What will this do:
> > >     for_every_part { if (some test here) { for_every_part { ... } } }
> > 
> > My inclination is to ban them, or at least allow an implementation-defined
> > limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> > almost anything in sieve by the base spec.)
> 
> 
> I would like the nested for_every_part to operate on the child nodes
> of the current context body part, not always operate on all the body
> parts of the root message.  This to me is the obvious behaviour.  If
> Ned wants to (understandably) ban them from his implementation, that's
> fine by me ;o) 


I don't see the point.  for_every_part will recurse through all headers,
so you'll do the test everywhere anyway.  if you like, you can set a
variable[1] and conditionally run "for_every_part" once more afterwards.
if "for_every_part" allowed you to restrict recursion (ie. a modifier
":onelevel"), I can possibly see the utility of nested calls.

[1] of course not guaranteed to be available, but assuming
implementation support, if the admin turned off variables, he's not
likely to support mime loops either.


> Although it isn't very explicit, I think I'm right in saying the
> default match type for mime is "is"?  So that means if :type matches
> against type/subtype, then I would be very confused if I wrote :type
> "text" and it didn't match against text/plain.



I'd think :type "text" was a syntax error or at best a leftover from RFC
1049.  I'd expect the "text/*" syntax I see for MIME types everywhere
else, but of course ":is" must (probably MUST, but I didn't check) be
the default match type for consistency with the rest of Sieve.


> I suggest:
> - :type to match against type, 
> - :subtype to match against subtype
> - :contenttype to match against type/subtype


my suggestion:

      * :type to match against full "media type/subtype"
      * :mediatype to match against just "media type"
      * :subtype to match against just "subtype"


although I _really_ think the latter two are redundant.
-- 
Kjetil T.


--=-h7Ln7RcOAxUVddDOzd9t
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.0">
</HEAD>
<BODY>
On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; &gt; #1: Need to deal with nested for_every_part loops. What will this do:</FONT>
<FONT COLOR="#000000">&gt; &gt;     for_every_part { if (some test here) { for_every_part { ... } } }</FONT>
<FONT COLOR="#000000">&gt; </FONT>
<FONT COLOR="#000000">&gt; My inclination is to ban them, or at least allow an implementation-defined</FONT>
<FONT COLOR="#000000">&gt; limit which can be set to 1. (Actually, such a limit is allowed implicitly for</FONT>
<FONT COLOR="#000000">&gt; almost anything in sieve by the base spec.)</FONT>

</PRE>
    <FONT COLOR="#000000">I would like the nested for_every_part to operate on the child nodes of the current context body part, not always operate on all the body parts of the root message.  This to me is the obvious behaviour.  If Ned wants to (understandably) ban them from his implementation, that's fine by me ;o) </FONT><BR>
</BLOCKQUOTE>
<BR>
I don't see the point.&nbsp;<TT> for_every_part</TT> will recurse through all headers, so you'll do the test everywhere anyway.&nbsp; if you like, you can set a variable[1] and conditionally run &quot;<TT>for_every_part</TT>&quot; once more afterwards.&nbsp; if &quot;<TT>for_every_part</TT>&quot; allowed you to restrict recursion (ie. a modifier &quot;<TT>:onelevel</TT>&quot;), I can possibly see the utility of nested calls.<BR>
<BR>
[1] of course not guaranteed to be available, but assuming implementation support, if the admin turned off variables, he's not likely to support mime loops either.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Although it isn't very explicit, I think I'm right in saying the default match type for mime is &quot;is&quot;?  So that means if :type matches against type/subtype, then I would be very confused if I wrote :type &quot;text&quot; and it didn't match against text/plain.</FONT>
</BLOCKQUOTE>
<PRE>

</PRE>
I'd think <TT>:type &quot;text&quot;</TT> was a syntax error or at best a leftover from RFC 1049.&nbsp; I'd expect the &quot;<TT>text/*</TT>&quot; syntax I see for MIME types everywhere else, but of course &quot;<TT>:is</TT>&quot; must (probably MUST, but I didn't check) be the default match type for consistency with the rest of Sieve.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I suggest:</FONT>
<FONT COLOR="#000000">- :type to match against type, </FONT>
<FONT COLOR="#000000">- :subtype to match against subtype</FONT>
<FONT COLOR="#000000">- :contenttype to match against type/subtype</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
my suggestion:
<>
    <LI><TT>:type</TT> to match against full &quot;<I>media type/subtype</I>&quot;
    <LI><TT>:mediatype</TT> to match against just &quot;<I>media type</I>&quot;
    <LI><TT>:subtype</TT> to match against just &quot;<I>subtype</I>&quot;
</UL>
<BR>
although I _<B>really</B>_ think the latter two are redundant.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Kjetil T.

</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-h7Ln7RcOAxUVddDOzd9t--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2PIgmP5056875; Sat, 25 Mar 2006 11:42:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2PIgmF4056874; Sat, 25 Mar 2006 11:42:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2PIgl55056868 for <[e-mail]>; Sat, 25 Mar 2006 11:42:47 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 25 Mar 2006 10:42:42 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 25 Mar 2006 09:26:25 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: document status: 3028bis, body, editheader
In-reply-to: "Your message dated Thu, 23 Mar 2006 06:07:47 +0100" <[e-mail]>
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 Wed, 2006-03-22 at 16:12 -0800, Ned Freed wrote:
> > > I find the description of the awkwardness of "\\" highly amusing
> > > juxtaposed with the requirement of all tests in Sieve[1] to have the
> > > argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> > > "require" statement).
> >
> > One man's meat is another man's poison... There are plenty of scripts that
> > depend on comparators continuing to work the way they always have.

> that doesn't mean we can't find a better way than the above.

Even assuming we can "find a better way" (we haven't done so thus far) for
future scripts to use, the installed base issue remains.

> I thought Dave Cridland's suggestion to specify matching behaviour in
> the comparator itself was intriguing:

> http://permalink.gmane.org/gmane.ietf.mta-filters/2689

> unfortunately, [draft-newman-i18n-comparator-08] says «the equality test
> MUST be reflexive, symmetric and transitive», so "EQUAL" can't be used.
> I must admit I don't quite understand how :matches and :regex work with
> comparators, though.

I think of it this way: A comparator has as one of it's components a
normalization operation. Pull that operation out, apply it, and then perform
the glob or regex operation on the result. Note that the output of the
normalization is best seen as a series of nonnegative integers or someting
similar, not octets or characters.

> another possibility is to have a capability which adds an action which
> changes the default comparator to reduce the verbosity.

It makes scripts a bit shorter, but at the expense of having something with
far-reaching impact specified at the top and not where the impact is felt. I'm
far from convinced this is a good tradeoff.

> another possibility is to allow the wildcard comparator, so
> that :comparator "*" «[selects] the collation with the broadest scope
> (preferably international scope), the most recent table versions and the
> greatest number of supported operations.»  (the comparators the server
> chooses from would have to be "require"d in advance, I think, although
> «require "comparator-*"» is a possibility)

I really don't like this - now you have scripts working in subtlely different 
ways in different places. This is big steps backwards, I think.

> > > to be honest, I find it absurd that such verbiage
> > > is forced upon users.  we need to find a better way.
> >
> > > [1] outside of the US of A, anyway.
> >
> > This has nothing to do with geography and everything to do with backwards
> > compatibility. Some of the scripts I'm referring to were written and are used
> > outside the US.
> >
> > And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
> > illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> > experience at least.

> this is impossible today, isn't it?

It is done all the time and the base specification allows it, more or less.

> how do you specify the string to compare with?

You just do it. Nothing in the current sieve specification says that it is an
error to specify material that isn't valid utf-8. (This is now prohibited by
the ABNF in the revised base specification, and IMO this restriction needs to
be removed for string constants. It is at a minimum in direct conflict with the
vacation specification.)

> in any case, if you want to trap raw non-UTF8 in headers,
> you should use i;octet.

Agreed, but in practice scripts often don't specify this.

>  but then again:

> 5.7.  Octet Collation

>    The i;octet (Section 9.5) collation is only usable with protocols
>    based on octet-strings.  Clients and servers MUST NOT use i;octet
>    with other protocols.

> which would disqualify the use of i;octet with Sieve, since 3028bis says:

>    The language is represented in UTF-8, as specified in [UTF-8].

Represent doesn't mean things are restricted to UTF-8. If it did it would be in
direct conflict with later language in the same document, which quite
specifically allows material in other charsets in strings.

The wording is a bit peculiar (and it needs to be clarified in the revision),
but the intent here was for UTF-8 to always be assumed when it was necessary to
assume a charset. So, in something like a string argument to fileinto, the
argument is to be interpreted in utf-8, never anything else. But in something
like, say, a whole MIME object, you have to be able to specify stuff in other
charsets.

Now, the base specification doesn't come out and say you can use this ability
in a header test. So I suppose it can be argued that it is more or less open as
to how an implementation should behave when this is done, which is why I said
"more or less" previously.

> the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
> clear to me that a 3028bis can get the same exemption.

It better or backwards compaatibility goes down the toilet, which is not
acceptable as far as I'm concerned.

> notice that
> "represented in UTF-8" only means constant strings can't contain raw
> octets which are illegal UTF-8 sequences.

I disagree 100% that that is what it means. And since the specification later
talks about putting non-UTF-8 material in constant strings in section 2.4.2.4,
it seems it agrees with me.

> which brings us back to the
> discussion on character escapes from a year ago.

> http://comments.gmane.org/gmane.ietf.mta-filters/2030

> I'd like to suggest we implement (2), but with the extension defined in
> the base spec.

I have no problem with this and would like to see it happen, but it may or may
not be relevant to the matter at hand. Regardless of whether you write some
sequence that's illegal in UTF-8 directly as a series of octets in a string
constant or indirectly using some sort of encoding, you're still presenting the
sieve interpreter with text that isn't in utf-8 at some level. Any attempt to
enforce some sort of rule that nothing but utf-8 can be present is still going
to fail. And any +Unnnn sort of scheme is inherently incapable of representing
UTF-8 anyway.

The ability to write octets using some sort of encoding is certainly helpful
when the script is presented in an editor or otherwise displayed. And the
intent of the resulting script is much much much clearer. That's why I support
the extension, not because it adds a capability that isn't there now.

> note that if the base spec adds the restriction on
> extensions that they can't modify other "require" statements, the
> analysis of string escapes can be performed statically by a byte
> compiler.

Agreed.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OKZWof073709; Fri, 24 Mar 2006 13:35:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OKZWAB073708; Fri, 24 Mar 2006 13:35:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2OKZVjZ073702 for <[e-mail]>; Fri, 24 Mar 2006 13:35:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17864 invoked by uid 101); 24 Mar 2006 15:35:30 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 24 Mar 2006 15:35:30 -0500
To: Nigel Swinson <[e-mail]>
Cc: Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Sieve mime loop issues list
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <003401c64f44$657bf230$9b42c050@nigelhome>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003401c64f44$657bf230$9b42c050@nigelhome>
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, Mar 24, 2006 at 01:10:58PM -0000, Nigel Swinson wrote:
> > > #1: Need to deal with nested for_every_part loops. What will this do:
> > >     for_every_part { if (some test here) { for_every_part { ... } } }
> > 
> > My inclination is to ban them, or at least allow an implementation-defined
> > limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> > almost anything in sieve by the base spec.)
> 
> I would like the nested for_every_part to operate on the child nodes
> of the current context body part, not always operate on all the body
> parts of the root message.  This to me is the obvious behaviour.  If Ned
> wants to (understandably) ban them from his implementation, that's fine
> by me ;o)

I agree.  Whether script writers will actually make use of such a
construct may be in question, but I am in favor of at least not
prohibiting it.  Per above, the draft could say that an implementation
must only support only 1 level of nesting but may support more.


> 
> > > #2: Need to decide if there would be a "mime" shorthand for testing the
> > > type/subtype, without requiring
> > 
> > >     if allof (mime :type "multipart", mime :subtype "alternative") ?
> > 
> > How about getting rid of :subtype and making :type check the whole thing? A
> > subtype is only meaningful in the context of a particular type; the only
> > exception to this are suffix tags, and checking those would require :matches
> > anyway. 
> >
> > And :matches can easily be used to check the primary type by itself. I see no
> > strong reason to prefer
> > 
> >     if mime :type "text" ...
> > 
> > over
> > 
> >     if mime :type :matches "text/*" ...
>  
> Although it isn't very explicit, I think I'm right in saying the
> default match type for mime is "is"?  So that means if :type matches
> against type/subtype, then I would be very confused if I wrote :type
> "text" and it didn't match against text/plain.

This because the word ":type" makes one think of "type" part of the
content type description?  (i.e., with a different :tag you wouldn't be
as confused?)  Personally I don't see it as all that confusing, but I
see the point, and a different :name would be reasonable.

 
> I suggest:
> - :type to match against type, 
> - :subtype to match against subtype
> - :contenttype to match against type/subtype

Having just one that selects the entire type/subtype string, allowing
the application of different match-types to the test, would make :type
and :subtype options somewhat redundant.  However, having :type and
:subtype don't really hurt, and are easy to implement.  But I think the
most important point is to have an option to test the entire string,
since as I mentioned

    allof (mime :anychild :type "multipart",
           mime :anychild :subtype "alternative")
and
    mime :anychild :contenttype "multipart/alternative"

are not necessarily equivalent (if the sub-tests of the first one match
different children).  Granted, there aren't that many subtypes that are
duplicated across the mime types world, and the above is not the best
example (maybe something with "xml" would be better), but that doesn't
mean we shouldn't be able to have a reliable atomic test.


> I prefer
> 
> >     header :mime
> >     exists :mime
> >     address :mime
> 
> Over 
> 
> >    mimeheader
> >    mimeexists
> >    mimeaddress

ditto

-mm-



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OISo7X068818; Fri, 24 Mar 2006 11:28:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OISoE6068817; Fri, 24 Mar 2006 11:28:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OISnwY068810 for <[e-mail]>; Fri, 24 Mar 2006 11:28:50 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id EB4ABD43053; Fri, 24 Mar 2006 13:27:53 -0500 (EST)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Fri, 24 Mar 2006 13:27:44 -0500
X-Sasl-enc: pzzNqNztZm59V1upxKBrkPlh6fT3jXxn0FuQBcNtlFs6 1143223269
Received: from [172.20.101.119] (unknown [12.47.253.67]) by www.fastmail.fm (Postfix) with ESMTP id F0D2821DA; Fri, 24 Mar 2006 13:01:08 -0500 (EST)
Date: Fri, 24 Mar 2006 12:01:16 -0500
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, Tony Hansen <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: Sieve mime loop issues list
Message-ID: <[e-mail]>
In-Reply-To: <003401c64f44$657bf230$9b42c050@nigelhome>
References: <[e-mail]> <[e-mail]> <003401c64f44$657bf230$9b42c050@nigelhome>
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
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 Nigel,

--On March 24, 2006 12:10:58 PM +0000 Nigel Swinson 
<[e-mail]> wrote:

> I prefer
>
>>     header :mime
>>     exists :mime
>>     address :mime
>
> Over
>
>>    mimeheader
>>    mimeexists
>>    mimeaddress

I prefer your preference too - since I will be updating the doc I will go 
ahead with this approach unless there are any objections.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OEuT1w059037; Fri, 24 Mar 2006 07:56:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OEuTeX059036; Fri, 24 Mar 2006 07:56:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OEuStP059021 for <[e-mail]>; Fri, 24 Mar 2006 07:56:29 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 044314AC28; Fri, 24 Mar 2006 15:56:27 +0100 (CET)
Message-Id: <[e-mail]>
Date: Fri, 24 Mar 2006 15:56:36 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Generalizing subaddress
Cc: Ken Murchison <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]> <sQ00HAs+c8OKR/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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 writes:
> I'm mildly concerned you're infringing on (9) and (10), but if we're 
> going to dump any idea of addressing subaddresses further [if you can 
> follow that] then I'd like to canvas implementors on what they think 
> a subaddress is, whether it sometimes/usually fits this description, 
> and whether we might as well chop it further. (Say, by insisting on a 
> '+' postfix ).
>
> FWIW, trying to bend in VERP and similar mechanisms strikes me as (5).

Hm.

That's not what I tried. I tried to define separator strongly enough 
that it can be used, and weakly enough that no implementer thinks he 
can process other people's subaddresses except as a 100% opaque 
address.

>> Arnt
>> (who thinks 1925 should be on the standards track)
>
> I think you could advance it straight to Draft status on the basis of 
> multiple independent interoperable implementations, at least.

Oh? The last adjective seems rather out of place ;)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OElFNo058675; Fri, 24 Mar 2006 07:47:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OElFh6058674; Fri, 24 Mar 2006 07:47:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OElDqJ058668 for <[e-mail]>; Fri, 24 Mar 2006 07:47:14 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FMnZH-0005ch-Sg for [e-mail]; Fri, 24 Mar 2006 15:47:11 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #1) id 1FMnZH-0002vn-Qp for [e-mail]; Fri, 24 Mar 2006 15:47:11 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61-RC1 #1) id 1FMnZH-0003Rf-Bp for [e-mail]; Fri, 24 Mar 2006 15:47:11 +0100
Date: Fri, 24 Mar 2006 15:47:11 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Generalizing subaddress
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>

> >I was tasked at Tuesday's Sieve WG meeting with trying to make the 
> >language in the subaddress draft even more general than it 
> >currently is, but as Philip noted in another thread, doing so makes 
> >it very difficult to describe when :detail is present/empty/not 
> >present.  I have not found a way to describe these states without 
> >relying on some type of 'delimiter' or 'separator'.

If the encoding of a detail depends on the target address, determining
if it contains no, an empty or a non-empty detail part depends on the
target address, too.  It can not be described in the subaddress extension.

I suggest:

   The ":detail" argument specifies the detail sub-part of the local-part
   of an address.  The encoding of the detail sub-part is dependent on
   the encompassing mail system and recipient address.  If the recipient
   address is not encoded to contain a detail part, the test evaluates
   to false.  An encoded empty detail information causes an empty key
   ("").

Something sounds wrong there, but a native speaker can certainly fix it.

> I think much of Ken's problem here is that he's trying to build a 
> standard method for doing something with unstandardized local part 
> formats.

Exactly.

> Perhaps what's actually needed is some kind of informational document 
> describing various mechanisms that exist for subaddressing and 
> similar local-part "encodings", and then using the subaddress Sieve 
> extension to access those encodings.

I agree, although I would like to keep that purely informational and allow
the extension to make use of methods not described in such a document.
Yet it may reduce the amount of new encoding schemes arising just because
people never saw existing approaches to the problem.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODtFFG056229; Fri, 24 Mar 2006 06:55:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ODtFr9056228; Fri, 24 Mar 2006 06:55:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODtEkt056221 for <[e-mail]>; Fri, 24 Mar 2006 06:55:14 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FMmkx-0004wv-3X; Fri, 24 Mar 2006 13:55:11 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 98A58498003; Fri, 24 Mar 2006 13:58:57 +0000 (GMT)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31615-04; Fri, 24 Mar 2006 13:58:48 +0000 (GMT)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2ECDE498002; Fri, 24 Mar 2006 13:58:46 +0000 (GMT)
Date: Fri, 24 Mar 2006 13:54:59 +0000
Subject: Re: Generalizing subaddress
References: <[e-mail]> <[e-mail]> <sQ00HAs+c8OKR/[e-mail]>
In-Reply-To: <sQ00HAs+c8OKR/[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Ken Murchison <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
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 Mar 24 13:43:29 2006, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
>> 
>>> I was tasked at Tuesday's Sieve WG meeting with trying to make 
>>> the language in the subaddress draft even more general than it 
>>> currently is, but as Philip noted in another thread, doing so 
>>> makes it very difficult to describe when :detail is 
>>> present/empty/not present.  I have not found a way to describe 
>>> these states without relying on some type of 'delimiter' or 
>>> 'separator'.
>>> 
>>> Consider this a plea for some suggested text.
>> 
>> I think much of Ken's problem here is that he's trying to build a 
>> standard method for doing something with unstandardized local part 
>> formats.
> 
> Agreed.
> 
>> Perhaps what's actually needed is some kind of informational 
>> document describing various mechanisms that exist for 
>> subaddressing and similar local-part "encodings", and then using 
>> the subaddress Sieve extension to access those encodings.
> 
> Maybe. But that paragraph brings forth RFC 1925 in my mind. 
> Specifically, 6a, but also 6, 7, 7a and 8.
> 
> 
You have a sound point, although my premise for moving the definition 
to a distinct document was primarily because it's useful on its own, 
see (5).


> How about just specifying that
> a) this extension is limited to subaddresses which use separators,
> b) a future extension may lift that restriction, and
> c) the separator may consist of one character, of several 
> characters or even of a zero-width boundary such as e.g. "letter on 
> one side, nonletter on the other"?
> 
> 
I'm mildly concerned you're infringing on (9) and (10), but if we're 
going to dump any idea of addressing subaddresses further [if you can 
follow that] then I'd like to canvas implementors on what they think 
a subaddress is, whether it sometimes/usually fits this description, 
and whether we might as well chop it further. (Say, by insisting on a 
'+' postfix ).

FWIW, trying to bend in VERP and similar mechanisms strikes me as (5).


> Arnt
> (who thinks 1925 should be on the standards track)

I think you could advance it straight to Draft status on the basis of 
multiple independent interoperable implementations, at least.

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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODhMGB055837; Fri, 24 Mar 2006 06:43:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ODhMcR055836; Fri, 24 Mar 2006 06:43:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODhLWC055830 for <[e-mail]>; Fri, 24 Mar 2006 06:43:21 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E2C874AC28; Fri, 24 Mar 2006 14:43:19 +0100 (CET)
Message-Id: <sQ00HAs+c8OKR/[e-mail]>
Date: Fri, 24 Mar 2006 14:43:29 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Generalizing subaddress
Cc: Ken Murchison <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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 writes:
> On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
>
>> I was tasked at Tuesday's Sieve WG meeting with trying to make the 
>> language in the subaddress draft even more general than it currently 
>> is, but as Philip noted in another thread, doing so makes it very 
>> difficult to describe when :detail is present/empty/not present.  I 
>> have not found a way to describe these states without relying on 
>> some type of 'delimiter' or 'separator'.
>>
>> Consider this a plea for some suggested text.
>
> I think much of Ken's problem here is that he's trying to build a 
> standard method for doing something with unstandardized local part 
> formats.

Agreed.

> Perhaps what's actually needed is some kind of informational document 
> describing various mechanisms that exist for subaddressing and 
> similar local-part "encodings", and then using the subaddress Sieve 
> extension to access those encodings.

Maybe. But that paragraph brings forth RFC 1925 in my mind. 
Specifically, 6a, but also 6, 7, 7a and 8.

How about just specifying that
a) this extension is limited to subaddresses which use separators,
b) a future extension may lift that restriction, and
c) the separator may consist of one character, of several characters or 
even of a zero-width boundary such as e.g. "letter on one side, 
nonletter on the other"?

Arnt
(who thinks 1925 should be on the standards track)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODDmQk054388; Fri, 24 Mar 2006 06:13:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ODDmxK054387; Fri, 24 Mar 2006 06:13:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODDl1U054381 for <[e-mail]>; Fri, 24 Mar 2006 06:13:48 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FMm6n-0002Fq-Uw; Fri, 24 Mar 2006 13:13:42 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BEA9F498004; Fri, 24 Mar 2006 13:17:27 +0000 (GMT)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31256-10; Fri, 24 Mar 2006 13:17:19 +0000 (GMT)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 4C311498002; Fri, 24 Mar 2006 13:17:17 +0000 (GMT)
Date: Fri, 24 Mar 2006 13:13:30 +0000
Subject: Re: Generalizing subaddress
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Ken Murchison <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
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 Mar 24 00:25:37 2006, Ken Murchison wrote:
> 
> I was tasked at Tuesday's Sieve WG meeting with trying to make the 
> language in the subaddress draft even more general than it 
> currently is, but as Philip noted in another thread, doing so makes 
> it very difficult to describe when :detail is present/empty/not 
> present.  I have not found a way to describe these states without 
> relying on some type of 'delimiter' or 'separator'.
> 
> Consider this a plea for some suggested text.

I think much of Ken's problem here is that he's trying to build a 
standard method for doing something with unstandardized local part 
formats.

Perhaps what's actually needed is some kind of informational document 
describing various mechanisms that exist for subaddressing and 
similar local-part "encodings", and then using the subaddress Sieve 
extension to access those encodings.

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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODAsbH054295; Fri, 24 Mar 2006 06:10:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ODAsFE054294; Fri, 24 Mar 2006 06:10:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ODAsPe054288 for <[e-mail]>; Fri, 24 Mar 2006 06:10:54 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.206]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Fri, 24 Mar 2006 05:10:48 -0800
Message-ID: <003401c64f44$657bf230$9b42c050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Tony Hansen" <[e-mail]>
Cc: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Sieve mime loop issues list
Date: Fri, 24 Mar 2006 13:10:58 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2ODAsPe054289
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>

> > #1: Need to deal with nested for_every_part loops. What will this do:
> >     for_every_part { if (some test here) { for_every_part { ... } } }
> 
> My inclination is to ban them, or at least allow an implementation-defined
> limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> almost anything in sieve by the base spec.)

I would like the nested for_every_part to operate on the child nodes of the current context body part, not always operate on all the body parts of the root message.  This to me is the obvious behaviour.  If Ned wants to (understandably) ban them from his implementation, that's fine by me ;o) 

> > #2: Need to decide if there would be a "mime" shorthand for testing the
> > type/subtype, without requiring
> 
> >     if allof (mime :type "multipart", mime :subtype "alternative") ?
> 
> How about getting rid of :subtype and making :type check the whole thing? A
> subtype is only meaningful in the context of a particular type; the only
> exception to this are suffix tags, and checking those would require :matches
> anyway. 
>
> And :matches can easily be used to check the primary type by itself. I see no
> strong reason to prefer
> 
>     if mime :type "text" ...
> 
> over
> 
>     if mime :type :matches "text/*" ...

Although it isn't very explicit, I think I'm right in saying the default match type for mime is "is"?  So that means if :type matches against type/subtype, then I would be very confused if I wrote :type "text" and it didn't match against text/plain.

I suggest:
- :type to match against type, 
- :subtype to match against subtype
- :contenttype to match against type/subtype

> > #3: We need to add some way to look at parameter lists:
> >     Content-Type: text/plain; charset="foo"

I currently have:

 MimeClause ::= "x_mime" [COMPARATOR] [MATCH-TYPE]
 <header-list: string-list> [<parameter-list: string-list>] <key-list: string-list>
 MimeClause ::= "x_mime" :filename <key-list: string-list>
 MimeClause ::= "x_mime" :type <key-list: string-list>
 MimeClause ::= "x_mime" :subtype <key-list: string-list>

So if you don't have a :type/:subtype/:filename, then you must specify a list of header names, a list of parameter names, and the search strings.  "type" and "subtype" are supported as psuedo parameter names of the bit before the first ";".  If there are no parameter names, then it matches against the text before the first ";".  :type/:subtype/:filename then become short hands:

mime :type "text"
mime "Content-Type" "type" "text

mime :subtype "plain"
mime "Content-Type" "subtype" "plain"

mime :filename "junk.txt"
anyof (
    mime "Content-Disposition" "filemane""junk.txt"'
    mime "Content-Type" "name" "junk.txt"
)
 
> > The following issues/comments were raised at the meeting:
> >     interactions with variables
> >     notifications
> >     notifications to calendar service
> >     address tests, exists tests
> >     add tests mimeheader, mimeparameter
> 

I prefer

>     header :mime
>     exists :mime
>     address :mime

Over 

>    mimeheader
>    mimeexists
>    mimeaddress
> 
> but I do want to see some way to do address and exists tests on inner
> headers. This is actually quite a bit more important than a parameter
> test IMO.

I agree

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O1Sve2022963; Thu, 23 Mar 2006 18:28:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2O1Svc8022962; Thu, 23 Mar 2006 18:28:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O1SuRL022956 for <[e-mail]>; Thu, 23 Mar 2006 18:28:57 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 23 Mar 2006 17:28:53 -0800 (PST)
Cc: Ned Freed <[e-mail]>, IETF MTA Filters List <[e-mail]>
To: Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 23 Mar 2006 17:26:01 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve mime loop issues list
In-reply-to: "Your message dated Thu, 23 Mar 2006 16:56:46 -0800" <[e-mail]>
MIME-version: 1.0
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>

> Ned Freed <[e-mail]> writes:
> >> #3: We need to add some way to look at parameter lists:
> >>     Content-Type: text/plain; charset="foo"
> >
> >Agreed, but mostly because of RFC 2231.

> It also avoids problems with comments and quoting (dang structured fields!).


> ...
> >but I do want to see some way to do address and exists tests on inner
> >headers. This is actually quite a bit more important than a parameter
> >test IMO.

> Do you mean "the MIME header of inner parts" or do you mean "the
> headers of nested message/rfc822 parts"?   If both, how should they
> be differentiated?

AFAIK we have not defined a field that involves an address for a MIME
part. So unless you want to avoid false matches on bogons in MIME parts,
I don't think this makes a difference.

In any case, you probably could rig up something to only test message/rfc822
parts using variables, assuming the traversal is top-down.

Chris Newman also suggests renaming this as foreach, in order to make it
clearer we're still not Turing-complete.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0um5m021681; Thu, 23 Mar 2006 17:56:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2O0umXK021680; Thu, 23 Mar 2006 17:56:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0ulPx021674 for <[e-mail]>; Thu, 23 Mar 2006 17:56:48 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2O0ukj5008859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 23 Mar 2006 16:56:46 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2O0ukj5008859
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1143161807; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:From:Subject:In-reply-to:References:Date:Sender; b=K APShYSgk2w8OGszUtPUyVpzWY2VEq3R3zPKO+wo7ZwSsfbP5U/VCCski5mVShxRpFHf dL1LqAnb4ukmjHm52ewWJ8+NtupoCb1wzFGeFazs4R7lwf32JGIDcT9bh57v1szUHAy cAaTMpw3hq07EoPt1rRC4rXy86I5eWDEBICw=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2O0ukj5008859
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:from:subject:in-reply-to: references:date:sender; b=sg4s3PPeVDxkhkL58SPm9nBepFq11/llHYTi5mVti6ewPCa8Yg8HhaO6bPknVv6KF aPMMFjNydP8Be0YxIdngc6mC5mYE5/7kmTNJWAP3vQ0jZaiBsN0HPs4w1OZRYbUas8V 1Pgd/jN4AMUV+ZaeVSlyo9UpF8Cg6zdfOj/Ic1U=
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 k2O0ukZu097713; Thu, 23 Mar 2006 16:56:46 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Sieve mime loop issues list 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Thu, 23 Mar 2006 16:56:46 -0800
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>

Ned Freed <[e-mail]> writes:
>> #3: We need to add some way to look at parameter lists:
>>     Content-Type: text/plain; charset="foo"
>
>Agreed, but mostly because of RFC 2231.

It also avoids problems with comments and quoting (dang structured fields!).


...
>but I do want to see some way to do address and exists tests on inner
>headers. This is actually quite a bit more important than a parameter
>test IMO.

Do you mean "the MIME header of inner parts" or do you mean "the
headers of nested message/rfc822 parts"?   If both, how should they
be differentiated?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0Pevp019960; Thu, 23 Mar 2006 17:25:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2O0PeTf019959; Thu, 23 Mar 2006 17:25:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0PcfW019953 for <[e-mail]>; Thu, 23 Mar 2006 17:25:39 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.129.139] (DHCP-Wireless-129-139.ietf65.org [130.129.129.139]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.5) with ESMTP id k2O0PYcH007726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 23 Mar 2006 19:25:38 -0500
Message-ID: <[e-mail]>
Date: Thu, 23 Mar 2006 19:25:37 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Generalizing subaddress
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>

I was tasked at Tuesday's Sieve WG meeting with trying to make the 
language in the subaddress draft even more general than it currently is, 
but as Philip noted in another thread, doing so makes it very difficult 
to describe when :detail is present/empty/not present.  I have not found 
a way to describe these states without relying on some type of 
'delimiter' or 'separator'.

Consider this a plea for some suggested text.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0HKEM019707; Thu, 23 Mar 2006 17:17:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2O0HKWx019706; Thu, 23 Mar 2006 17:17:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O0HJdE019700 for <[e-mail]>; Thu, 23 Mar 2006 17:17:19 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 23 Mar 2006 16:17:17 -0800 (PST)
Cc: IETF MTA Filters List <[e-mail]>
To: Tony Hansen <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 23 Mar 2006 15:30:29 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve mime loop issues list
In-reply-to: "Your message dated Thu, 23 Mar 2006 16:59:59 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
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>

> Here is the list of issues with the MIME LOOP draft that need to be
> worked on, as discussed at the Sieve meeting this week.

> #1: Need to deal with nested for_every_part loops. What will this do:
>     for_every_part { if (some test here) { for_every_part { ... } } }

My inclination is to ban them, or at least allow an implementation-defined
limit which can be set to 1. (Actually, such a limit is allowed implicitly for
almost anything in sieve by the base spec.)

> #2: Need to decide if there would be a "mime" shorthand for testing the
> type/subtype, without requiring

>     if allof (mime :type "multipart", mime :subtype "alternative") ?

How about getting rid of :subtype and making :type check the whole thing? A
subtype is only meaningful in the context of a particular type; the only
exception to this are suffix tags, and checking those would require :matches
anyway. That is, there's no practical difference between

    if mime :subtype :matches "*+xml" ...

and

    if mime :type : matches "*+xml" ...

And :matches can easily be used to check the primary type by itself. I see no
strong reason to prefer

    if mime :type "text" ...

over

    if mime :type :matches "text/*" ...

> #3: We need to add some way to look at parameter lists:
>     Content-Type: text/plain; charset="foo"

Agreed, but mostly because of RFC 2231.

> The following issues/comments were raised at the meeting:
>     interactions with variables
>     notifications
>     notifications to calendar service
>     address tests, exists tests
>     add tests mimeheader, mimeparameter

I'll repeat that I have no real preference between

    header :mime
    exists :mime
    address :mime

and

   mimeheader
   mimeexists
   mimeaddress

but I do want to see some way to do address and exists tests on inner
headers. This is actually quite a bit more important than a parameter
test IMO.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2NM082l013640; Thu, 23 Mar 2006 15:00:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2NM088B013639; Thu, 23 Mar 2006 15:00:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail124.messagelabs.com (mail124.messagelabs.com [85.158.136.19]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2NM040V013629 for <[e-mail]>; Thu, 23 Mar 2006 15:00:07 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-124.messagelabs.com!1143151201!8318654!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 9221 invoked from network); 23 Mar 2006 22:00:02 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-124.messagelabs.com with SMTP; 23 Mar 2006 22:00:02 -0000
Received: from [135.70.91.187] (unknown[135.70.91.187](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060323220001gw100100e5e> (Authid: tony); Thu, 23 Mar 2006 22:00:01 +0000
Message-ID: <[e-mail]>
Date: Thu, 23 Mar 2006 16:59:59 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Sieve mime loop issues list
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
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>

Here is the list of issues with the MIME LOOP draft that need to be
worked on, as discussed at the Sieve meeting this week.

#1: Need to deal with nested for_every_part loops. What will this do:
    for_every_part { if (some test here) { for_every_part { ... } } }

#2: Need to decide if there would be a "mime" shorthand for testing the
type/subtype, without requiring

    if allof (mime :type "multipart", mime :subtype "alternative") ?

#3: We need to add some way to look at parameter lists:
    Content-Type: text/plain; charset="foo"

The following issues/comments were raised at the meeting:
    interactions with variables
    notifications
    notifications to calendar service
    address tests, exists tests
    add tests mimeheader, mimeparameter

	Tony Hansen
	[e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2N57uJ1071425; Wed, 22 Mar 2006 22:07:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2N57uR8071424; Wed, 22 Mar 2006 22:07:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2N57sPm071418 for <[e-mail]>; Wed, 22 Mar 2006 22:07:55 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1FMI34-0002um-GQ; Thu, 23 Mar 2006 06:07:50 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FMI31-0001S3-T6; Thu, 23 Mar 2006 06:07:47 +0100
Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Thu, 23 Mar 2006 06:07:47 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.709, required 12, autolearn=disabled, AWL 0.29, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2N57tPm071419
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, 2006-03-22 at 16:12 -0800, Ned Freed wrote:
> > I find the description of the awkwardness of "\\" highly amusing
> > juxtaposed with the requirement of all tests in Sieve[1] to have the
> > argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> > "require" statement).
> 
> One man's meat is another man's poison... There are plenty of scripts that
> depend on comparators continuing to work the way they always have.

that doesn't mean we can't find a better way than the above.

I thought Dave Cridland's suggestion to specify matching behaviour in
the comparator itself was intriguing:

http://permalink.gmane.org/gmane.ietf.mta-filters/2689

unfortunately, [draft-newman-i18n-comparator-08] says «the equality test
MUST be reflexive, symmetric and transitive», so "EQUAL" can't be used.
I must admit I don't quite understand how :matches and :regex work with
comparators, though.

another possibility is to have a capability which adds an action which
changes the default comparator to reduce the verbosity.

another possibility is to allow the wildcard comparator, so
that :comparator "*" «[selects] the collation with the broadest scope
(preferably international scope), the most recent table versions and the
greatest number of supported operations.»  (the comparators the server
chooses from would have to be "require"d in advance, I think, although
«require "comparator-*"» is a possibility)

> > to be honest, I find it absurd that such verbiage
> > is forced upon users.  we need to find a better way.
> 
> > [1] outside of the US of A, anyway.
> 
> This has nothing to do with geography and everything to do with backwards
> compatibility. Some of the scripts I'm referring to were written and are used
> outside the US.
> 
> And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
> illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> experience at least.

this is impossible today, isn't it?  how do you specify the string to
compare with?  in any case, if you want to trap raw non-UTF8 in headers,
you should use i;octet.  but then again:

5.7.  Octet Collation

   The i;octet (Section 9.5) collation is only usable with protocols
   based on octet-strings.  Clients and servers MUST NOT use i;octet
   with other protocols.

which would disqualify the use of i;octet with Sieve, since 3028bis says:

   The language is represented in UTF-8, as specified in [UTF-8].

the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
clear to me that a 3028bis can get the same exemption.  notice that
"represented in UTF-8" only means constant strings can't contain raw
octets which are illegal UTF-8 sequences.  which brings us back to the
discussion on character escapes from a year ago.

http://comments.gmane.org/gmane.ietf.mta-filters/2030

I'd like to suggest we implement (2), but with the extension defined in
the base spec.  note that if the base spec adds the restriction on
extensions that they can't modify other "require" statements, the
analysis of string escapes can be performed statically by a byte
compiler.
-- 
Kjetil T.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2N0IDqg059327; Wed, 22 Mar 2006 17:18:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2N0IDx8059326; Wed, 22 Mar 2006 17:18:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2N0IDVp059320 for <[e-mail]>; Wed, 22 Mar 2006 17:18:13 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Mar 2006 16:18:10 -0800 (PST)
Cc: Philip Guenther <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 22 Mar 2006 16:12:07 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: document status: 3028bis, body, editheader
In-reply-to: "Your message dated Wed, 22 Mar 2006 23:24:33 +0100" <[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 Mon, 2006-03-20 at 22:59 -0800, Philip Guenther wrote:
> > I've made one tweak for the next rev to the wording in section 2.7.1
> > regarding ':match' and the definition of 'character'; I had overlooked
> > an off-list comment at the turn of the year.  The paragraph now
> > reads:
> >    The ":matches" match type specifies a wildcard match using the
> >    characters "*" and "?"; the entire value must be matched.  "*"
> >    matches zero or more characters in the value and "?" matches a single
> >    character in the value, where the comparator that is used (see 2.7.3)
> >    defines what a character is.  For example, the comparators "i;octet"
> >    and "en;ascii-casemap" define a character to be a single octet so "?"
> >    will always match exactly one octet when one of those comparators is
> >    in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
> >    defines a character to be any UTF-8 octet sequence encoding one
> >    Unicode character and thus "?" may match more than one octet.  "?"
> >    and "*" may be escaped as "\\?" and "\\*" in strings to match against
> >    themselves.  The first backslash escapes the second backslash;
> >    together, they escape the "*".  This is awkward, but it is
> >    commonplace in several programming languages that use globs and
> >    regular expressions.

> I find the description of the awkwardness of "\\" highly amusing
> juxtaposed with the requirement of all tests in Sieve[1] to have the
> argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> "require" statement).

One man's meat is another man's poison... There are plenty of scripts that
depend on comparators continuing to work the way they always have.

  to be honest, I find it absurd that such verbiage
> is forced upon users.  we need to find a better way.

> [1] outside of the US of A, anyway.

This has nothing to do with geography and everything to do with backwards
compatibility. Some of the scripts I'm referring to were written and are used
outside the US.

And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
experience at least.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MNuJPh058429; Wed, 22 Mar 2006 16:56:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MNuJiZ058428; Wed, 22 Mar 2006 16:56:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MNuHTt058420 for <[e-mail]>; Wed, 22 Mar 2006 16:56:18 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Mar 2006 15:56:12 -0800 (PST)
Cc: Philip Guenther <[e-mail]>, [e-mail]
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 22 Mar 2006 15:54:25 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 3028bis: post-meeting changes
In-reply-to: "Your message dated Wed, 22 Mar 2006 13:43:09 -0800" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
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>

> Philip Guenther wrote:

> >These are in response to the discussions earlier today in Dallas.
> >The log of the jabber room can be found at:
> >	http://www.ietf.org/meetings/ietf-logs/[e-mail]/2006-03-21.html
> >
> >
> >Opinions on any of the following, whether yeah or nay, are appreciated,
> >especially on the last point.
> >
> >
> >1. The first paragraph of section 4.1 ("Action fileinto") now reads:
> >
> >   The "fileinto" action delivers the message into the specified folder.
> >   Implementations SHOULD support fileinto, but in some environments
> >   this may be impossible.  Implementations MAY place restrictions on
> >   folder names; use of an invalid folder name MAY be treated as an
> >   error or result in delivery to an implementation-defined folder.  If
> >   the implementation uses a different encoding scheme than UTF-8 for
> >   folder names, it SHOULD reencode the folder name from UTF-8 to its
> >   encoding scheme.  For example, the Internet Message Access Protocol
> >   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
> >   ends" would appear in IMAP as "odds &- ends".
> >
> >
> I like that.

So do I. +1.

> >(Hmm, need to tweak the line wrap...)
> >
> >
> >2. In the Security Considerations section, I've added:
> >
> >    Use of the "redirect" command to generate notifications may
> >    easily overwhelm the target address, especially if it was not
> >    designed to handle large message.
> >
> >
> This is intentionally vague, but it is probably Ok with me.

Agree, but s/message./messages./

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MMOlYX054813; Wed, 22 Mar 2006 15:24:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MMOl4K054812; Wed, 22 Mar 2006 15:24:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MMOk6J054796 for <[e-mail]>; Wed, 22 Mar 2006 15:24:46 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1FMBkw-0000Al-KO; Wed, 22 Mar 2006 23:24:42 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FMBko-0007JS-Le; Wed, 22 Mar 2006 23:24:34 +0100
Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 22 Mar 2006 23:24:33 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.299, required 12, autolearn=disabled, AWL -0.30, 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, 2006-03-20 at 22:59 -0800, Philip Guenther wrote:
> I've made one tweak for the next rev to the wording in section 2.7.1
> regarding ':match' and the definition of 'character'; I had overlooked
> an off-list comment at the turn of the year.  The paragraph now
> reads:
>    The ":matches" match type specifies a wildcard match using the
>    characters "*" and "?"; the entire value must be matched.  "*"
>    matches zero or more characters in the value and "?" matches a single
>    character in the value, where the comparator that is used (see 2.7.3)
>    defines what a character is.  For example, the comparators "i;octet"
>    and "en;ascii-casemap" define a character to be a single octet so "?"
>    will always match exactly one octet when one of those comparators is
>    in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>    defines a character to be any UTF-8 octet sequence encoding one
>    Unicode character and thus "?" may match more than one octet.  "?"
>    and "*" may be escaped as "\\?" and "\\*" in strings to match against
>    themselves.  The first backslash escapes the second backslash;
>    together, they escape the "*".  This is awkward, but it is
>    commonplace in several programming languages that use globs and
>    regular expressions.

I find the description of the awkwardness of "\\" highly amusing
juxtaposed with the requirement of all tests in Sieve[1] to have the
argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
"require" statement).  to be honest, I find it absurd that such verbiage
is forced upon users.  we need to find a better way.

[1] outside of the US of A, anyway.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MM6Ao0053697; Wed, 22 Mar 2006 15:06:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MM6AFU053696; Wed, 22 Mar 2006 15:06:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MM6751053688 for <[e-mail]>; Wed, 22 Mar 2006 15:06:09 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1FMBSs-00049j-Uc; Wed, 22 Mar 2006 23:06:03 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FMBSn-0001wo-NS; Wed, 22 Mar 2006 23:05:57 +0100
Subject: Re: 3028bis: post-meeting changes
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 22 Mar 2006 23:05:51 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.197, required 12, autolearn=disabled, AWL -0.20, 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, 2006-03-21 at 19:09 -0800, Philip Guenther wrote:
>    encoding scheme.  For example, the Internet Message Access Protocol
>    [IMAP] uses modified UTF-7, such that a folder argument of "odds &
>    ends" would appear in IMAP as "odds &- ends".

the added text is good, but s/such/so/ ?  (I'm not a native speaker ...)

> 2. In the Security Considerations section, I've added:
> 
>     Use of the "redirect" command to generate notifications may
>     easily overwhelm the target address, especially if it was not
>     designed to handle large message.

if the target is just a plain e-mail account, this sounds like a bizarre
caveat, so perhaps "target service" or "target system" is better to get
into the right context.  (also s/message/messages/)

> Concerns about different capabilities enabling the same action or
> test are better addressed, IMHO, by reexamining the naming and
> review policy for the registry.
> 
> For example, perhaps we should
> 1) adjust the vendor namespace rules to instead be FCFS registration
>    of trees ("vnd.acme.*"),
> 2) break out a namespace for draft extensions (ala Alexey's
>    "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
> 3) switch the rest of the namespace from FCFS to Specification
>    required or IETF Consensus (c.f. RFC 2434)
> 
> I included (2) because we've had problems with extensions that saw
> significant change after a long period of statis (e.g., 'notify'
> and 'imapflags'), but perhaps the above is an overreaction.

all of these seem like overkill to me.

we could either suggest a version number be part of all capability
names, or we could just say the suffix "" is version 1, and tack on "2",
"3" etc as needed for the next versions.  we don't have to be creative
with every new "next generation" capability.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLpmJ5052908; Wed, 22 Mar 2006 14:51:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MLpmCd052907; Wed, 22 Mar 2006 14:51:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLplxi052901 for <[e-mail]>; Wed, 22 Mar 2006 14:51:48 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 22 Mar 2006 21:51:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 13:51:37 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: 3028bis: post-meeting changes
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>

Philip Guenther wrote:

>
>Concerns about different capabilities enabling the same action or
>test are better addressed, IMHO, by reexamining the naming and
>review policy for the registry.
>
>For example, perhaps we should
>1) adjust the vendor namespace rules to instead be FCFS registration
>   of trees ("vnd.acme.*"),
>2) break out a namespace for draft extensions (ala Alexey's
>   "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
>3) switch the rest of the namespace from FCFS to Specification
>   required or IETF Consensus (c.f. RFC 2434)
>
>I included (2) because we've had problems with extensions that saw
>significant change after a long period of statis (e.g., 'notify'
>and 'imapflags'), but perhaps the above is an overreaction.
>
Sounds good to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLoePV052869; Wed, 22 Mar 2006 14:50:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MLoeBc052868; Wed, 22 Mar 2006 14:50:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLod9R052862 for <[e-mail]>; Wed, 22 Mar 2006 14:50:40 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 22 Mar 2006 21:50:34 +0000
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 13:50:30 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: 3028bis: post-meeting changes
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>

Philip Guenther wrote:

>3. IANA template
>
>I think we should simply drop the "Capability name" and "Capability
>arguments" fields, leaving:
>
The proposal from the meeting was:
Have a require capability name.
Have a short description of what an extension does.
Have separate lists for all new tests/actions/etc., so that we can avoid 
incompatible action/test/etc. names between multiple extensions.

>   Capability keyword:
>   Standards Track/IESG-approved experimental RFC number:
>   Person and email address to contact for further information:
>
>As I see it, there are two major concerns for the registry:
> 1) capabilities should be unique, so that require "foo" has the
>    same meaning everywhere it works
> 2) given a standardized capability, you need to be able to find
>    the current RFC describing it
>
>Concerns about different capabilities enabling the same action or
>test are better addressed, IMHO, by reexamining the naming and
>review policy for the registry.
>
I still think have a single true place for listing all actions/tests is 
a good thing.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLhLFJ052635; Wed, 22 Mar 2006 14:43:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MLhLsq052634; Wed, 22 Mar 2006 14:43:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MLhKm7052628 for <[e-mail]>; Wed, 22 Mar 2006 14:43:21 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 22 Mar 2006 21:43:13 +0000
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 13:43:09 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: 3028bis: post-meeting changes
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>

Philip Guenther wrote:

>These are in response to the discussions earlier today in Dallas.
>The log of the jabber room can be found at:
>	http://www.ietf.org/meetings/ietf-logs/[e-mail]/2006-03-21.html
>
>
>Opinions on any of the following, whether yeah or nay, are appreciated,
>especially on the last point.
>
>
>1. The first paragraph of section 4.1 ("Action fileinto") now reads:
>
>   The "fileinto" action delivers the message into the specified folder.
>   Implementations SHOULD support fileinto, but in some environments
>   this may be impossible.  Implementations MAY place restrictions on
>   folder names; use of an invalid folder name MAY be treated as an
>   error or result in delivery to an implementation-defined folder.  If
>   the implementation uses a different encoding scheme than UTF-8 for
>   folder names, it SHOULD reencode the folder name from UTF-8 to its
>   encoding scheme.  For example, the Internet Message Access Protocol
>   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
>   ends" would appear in IMAP as "odds &- ends".
>  
>
I like that.

>(Hmm, need to tweak the line wrap...)
>
>
>2. In the Security Considerations section, I've added:
>
>    Use of the "redirect" command to generate notifications may
>    easily overwhelm the target address, especially if it was not
>    designed to handle large message.
>  
>
This is intentionally vague, but it is probably Ok with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MKXvq2050175; Wed, 22 Mar 2006 13:33:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MKXvNe050174; Wed, 22 Mar 2006 13:33:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MKXuH6050168 for <[e-mail]>; Wed, 22 Mar 2006 13:33:57 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Mar 2006 12:33:54 -0800 (PST)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 22 Mar 2006 12:33:41 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: document status: 3028bis, body, editheader
In-reply-to: "Your message dated Wed, 22 Mar 2006 21:09:51 +0100" <[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 Wed, Mar 22, 2006 at 11:07:55AM -0800, Ned Freed wrote:
> > > Fixing the draft to not use "header" when it means "header field"
> > > wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> > > Does anyone actually think that change would be a _bad_ thing?
> >
> > Sure sounds like a good thing to me. However, the material tested by header is
> > not, precisely speaking, the "body of the named header field". There's also
> > unfolding and decoding to consider. I suppose we could say "the unfolded and
> > decoded body of the named header field", although it's a bit of a mouthful.

> Insert a reference to RFC 2822 for unfolding and say MIME-decoded with
> a reference to RFC 2047 instead of decoded to make it worse, and I will
> be happy, too.  Honestly, I am glad for each bit of precision when it
> comes to specifications.

WFM

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MK9sTX048899; Wed, 22 Mar 2006 13:09:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MK9sNO048898; Wed, 22 Mar 2006 13:09:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MK9qi9048892 for <[e-mail]>; Wed, 22 Mar 2006 13:09:53 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FM9eR-0002Ku-GS for [e-mail]; Wed, 22 Mar 2006 21:09:51 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #1) id 1FM9eR-00010t-Ff for [e-mail]; Wed, 22 Mar 2006 21:09:51 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61-RC1 #1) id 1FM9eR-0001jC-4Z for [e-mail]; Wed, 22 Mar 2006 21:09:51 +0100
Date: Wed, 22 Mar 2006 21:09:51 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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 Wed, Mar 22, 2006 at 11:07:55AM -0800, Ned Freed wrote:
> > Fixing the draft to not use "header" when it means "header field"
> > wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> > Does anyone actually think that change would be a _bad_ thing?
> 
> Sure sounds like a good thing to me. However, the material tested by header is
> not, precisely speaking, the "body of the named header field". There's also
> unfolding and decoding to consider. I suppose we could say "the unfolded and
> decoded body of the named header field", although it's a bit of a mouthful.

Insert a reference to RFC 2822 for unfolding and say MIME-decoded with
a reference to RFC 2047 instead of decoded to make it worse, and I will
be happy, too.  Honestly, I am glad for each bit of precision when it
comes to specifications.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MJvHkj048353; Wed, 22 Mar 2006 12:57:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MJvHl5048352; Wed, 22 Mar 2006 12:57:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MJvGsJ048346 for <[e-mail]>; Wed, 22 Mar 2006 12:57:16 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FM9SE-0001MS-Vx for [e-mail]; Wed, 22 Mar 2006 20:57:15 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #1) id 1FM9SE-0001Bv-Ub for [e-mail]; Wed, 22 Mar 2006 20:57:14 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61-RC1 #1) id 1FM9SA-0001is-8N for [e-mail]; Wed, 22 Mar 2006 20:57:10 +0100
Date: Wed, 22 Mar 2006 20:57:10 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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 Wed, Mar 22, 2006 at 05:05:20PM +0100, Arnt Gulbrandsen wrote:
> Could you please elaborate?
> 
> Do you mean that ascii-casemap should consider two octet strings to be 
> equal if they are the same after decoding UTF-8?

That's what I would like indeed, but as I said, it would break all
implementations and for that reason and because RFC 3028 is interpreted
differently by the majority (read: anybody but me in the first place),
I doubt the change can happen.

> Should it do Unicode 
> composition/decomposition?

I don't know what that is, as I don't know much about Unicode at all.
Are you talking about encoding/decoding unicode characters in octets
or something different?

The way you ask implies that there are multiple ways how a unicode
character can be encoded in UTF-8.  Is that correct? I always assumed
UTF-8 was a 1:1 encoding of Unicode.

> As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
> string, namely 0x80 0x20, and that independently of whether 0x80 0x82 
> is meant to be a character encoded in UTF-8 or something else.

You raise a very interesting point.  How do I match this?

Subject: =?utf-8?q?=80=82?=

That sequence is not valid UTF-8 encoding.  Sieve scripts must be valid
UTF-8, so you can not match the above.  That is fine for comparators
operating on characters, but a true octet-wise comparator will be
crippled.  It has been suggested to encode each of the code points
0x80 and 0x82 in UTF-8 and the comparator had to decode the literal.
Very ugly, and I don't think existing implementations work that way.

As far as I remember, the consensus was: The above is a problem not
worth discussing.  Let Sieve scripts continue to be valid UTF-8, and
let's be unable to match certain values.  If anybody has a problem,
he better invents some kind of "raw" header test.  I agree.

Thus, we can't talk about the octet sequence 0x80 0x82 in Sieve. :-)

But I got distracted.  As long as we consider ":is" or ":contains",
there is no problem really, because both behave the same, no matter
if they decode UTF-8 or just work on octets, as long as we have valid
UTF-8 encoding.  The "?" wildcard is the problem: Should it match an
octet or a character?

Since all (most?) implementations ignore unicode and just work on octets,
"?" matches an octet, too.  Now that is weird to users, because if their
unicode aware client displays a one-character subject, "?" will only match
it if it is an US-ASCII character, and if it is a German umlaut character,
"??" matches it, because those are encoded in two octets.

That's where it becomes obvious if a comparator works on octets or
characters.  RFC 3028 does not specify that as clear as required and
the installed base unfortunately decided for octets, not characters.
The latest 3028bis draft follows that decision, and clearly so.

Of course the comparator specification has the last word on this.  I guess
you see the problem now, and should you decide that "en;ascii-case"
works on characters and "?" matches a unicode character, you had my vote
and I would change my implementation within 5 minutes.  *ducks and hides*

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MJB5V1046214; Wed, 22 Mar 2006 12:11:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MJB5hM046213; Wed, 22 Mar 2006 12:11:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MJB584046203 for <[e-mail]>; Wed, 22 Mar 2006 12:11:05 -0700 (MST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Mar 2006 11:11:01 -0800 (PST)
Cc: Mark E Mallett <[e-mail]>, [e-mail]
To: Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 22 Mar 2006 11:07:55 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: document status: 3028bis, body, editheader
In-reply-to: "Your message dated Wed, 22 Mar 2006 10:40:21 -0800" <[e-mail]>
MIME-version: 1.0
References: <[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>

> "Mark E. Mallett" <[e-mail]> writes:
> >On Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
> ...
> >> Section 5.7:
> >>    The "header" test evaluates to true if the value of any of the named
> >>    headers, ignoring leading and trailing whitespace, matches any key.
> >
> >Now this brings up the question of what the "value of a header" is.  In
> >RFC2822-speak, it would probably really be the "field body of the named
> >header fields" .  "header" is used a lot in the draft to mean "header
> >field" so that's probably not worth going into (much as I would love to
> >suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
> >better than the current rfc3028.

> Fixing the draft to not use "header" when it means "header field"
> wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> Does anyone actually think that change would be a _bad_ thing?

Sure sounds like a good thing to me. However, the material tested by header is
not, precisely speaking, the "body of the named header field". There's also
unfolding and decoding to consider. I suppose we could say "the unfolded and
decoded body of the named header field", although it's a bit of a mouthful.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MIeNdl045125; Wed, 22 Mar 2006 11:40:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MIeNpY045124; Wed, 22 Mar 2006 11:40:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MIeNxS045118 for <[e-mail]>; Wed, 22 Mar 2006 11:40:23 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2MIeLpe031708 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Mar 2006 10:40:21 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2MIeLpe031708
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1143052822; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:From:Cc:Subject:In-reply-to:References:Date:Sender; b=N /+5q8AB4Oq0Afv3I/8105eRx9zYOsGc/hg5LdJ7X+/KoWa84tT1FyTCSWCDk7stIGv1 8rJTPgqKJBXtBtrR8awwn//6p5bgf7YuvUyQRSFy+LlNgqgWFqWs84OdoWlPfOLcETx PqxMigFBYCJZgqTwCTNDjbfSL/jnbbAwrTrg=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2MIeLpe031708
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:from:cc:subject:in-reply-to: references:date:sender; b=pOEtuCYmOQyVI3y2Td/DOuLHhS6+73hsXWYmKWG+5051nwvNY/tGDVC9w8QCtA5aS xKfP5KXfZVbCgEnUTEOEc9pGGIlIBWco3PMjTnIh7AKTrtVkWunCfVJW0X6HXR9qeKp SLgG8e5epcQCuipi9Tfa8WTNrswAlfwdKKWN6Ac=
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 k2MIeL7N059034; Wed, 22 Mar 2006 10:40:21 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
From: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: document status: 3028bis, body, editheader 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Wed, 22 Mar 2006 10:40:21 -0800
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" <[e-mail]> writes:
>On Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
...
>> Section 5.7:
>>    The "header" test evaluates to true if the value of any of the named
>>    headers, ignoring leading and trailing whitespace, matches any key.
>
>Now this brings up the question of what the "value of a header" is.  In
>RFC2822-speak, it would probably really be the "field body of the named
>header fields" .  "header" is used a lot in the draft to mean "header
>field" so that's probably not worth going into (much as I would love to
>suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
>better than the current rfc3028.

Fixing the draft to not use "header" when it means "header field"
wouldn't be hard.  Ditto for aligning with 2822 on "field body".
Does anyone actually think that change would be a _bad_ thing?


...
>BTW I notice that in 5.1:
>
>   The address test matches Internet addresses ...
>
>this is the only one of the descriptions in section 5 that doesn't put
>the verb in quotes in its opening sentence.  <..>

Fixed.  I've also fixed the 'anyof' and 'allof' tests to match.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MICAlq043394; Wed, 22 Mar 2006 11:12:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MIC9Ei043393; Wed, 22 Mar 2006 11:12:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2MIC8qi043379 for <[e-mail]>; Wed, 22 Mar 2006 11:12:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 73452 invoked by uid 101); 22 Mar 2006 13:12:07 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 22 Mar 2006 13:12:07 -0500
To: Philip Guenther <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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 Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
> Alexey Melnikov <[e-mail]> writes:
> ...
> >I think you've missed a couple of issues I've reported:
> >1). I can't see any text about stripping leading/trailing whitespaces 
> >(text moved from the relational extension)
> 
> Section 5.7:
>    The "header" test evaluates to true if the value of any of the named
>    headers, ignoring leading and trailing whitespace, matches any key.

Now this brings up the question of what the "value of a header" is.  In
RFC2822-speak, it would probably really be the "field body of the named
header fields" .  "header" is used a lot in the draft to mean "header
field" so that's probably not worth going into (much as I would love to
suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
better than the current rfc3028.  To illustrage (not very good, but clearer):

    The "header" test compares the body of the named headers against the
    specified keys.  For the purpose of this test, The body of a
    header is what remains after removing the header's name and its
    following colon, and then ignoring any leading and trailing whitespace.

Then in:

   If a header listed in the header-names argument exists, it contains
   the empty key ("").  However, if the named header is not present, it
   does not match any key, including the empty key.  So if a message
   contained the header

would be "its body contains" and "its body does not contain"


BTW I notice that in 5.1:

   The address test matches Internet addresses ...

this is the only one of the descriptions in section 5 that doesn't put
the verb in quotes in its opening sentence.  i.e. for consistency's sake
it would be

   The "address" test ..

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MG6h47037431; Wed, 22 Mar 2006 09:06:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MG6hIw037430; Wed, 22 Mar 2006 09:06:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MG6hQ3037424 for <[e-mail]>; Wed, 22 Mar 2006 09:06:43 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4071B4AC1B; Wed, 22 Mar 2006 17:06:42 +0100 (CET)
Message-Id: <IVneJJu5Ik+ZhcCiLXo/[e-mail]>
Date: Wed, 22 Mar 2006 17:06:42 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
Cc: Michael Haardt <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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 wrote:
> As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
> string, namely 0x80 0x20,

Ack! Typo. 0x80 0x82 both time, of course



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MG5Mq2037379; Wed, 22 Mar 2006 09:05:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MG5MMe037378; Wed, 22 Mar 2006 09:05:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MG5LXg037372 for <[e-mail]>; Wed, 22 Mar 2006 09:05:21 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 58ADA4AC1B; Wed, 22 Mar 2006 17:05:20 +0100 (CET)
Message-Id: <[e-mail]>
Date: Wed, 22 Mar 2006 17:05:20 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
Cc: Michael Haardt <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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>

Could you please elaborate?

Do you mean that ascii-casemap should consider two octet strings to be 
equal if they are the same after decoding UTF-8? Should it do Unicode 
composition/decomposition?

As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
string, namely 0x80 0x20, and that independently of whether 0x80 0x82 
is meant to be a character encoded in UTF-8 or something else.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFpaaa036693; Wed, 22 Mar 2006 08:51:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MFpaXP036692; Wed, 22 Mar 2006 08:51:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFpZJq036684 for <[e-mail]>; Wed, 22 Mar 2006 08:51:35 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FM5cT-0007XH-S2 for [e-mail]; Wed, 22 Mar 2006 16:51:33 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #1) id 1FM5cT-0006Rb-NN for [e-mail]; Wed, 22 Mar 2006 16:51:33 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61-RC1 #1) id 1FM5cT-0001dl-CV for [e-mail]; Wed, 22 Mar 2006 16:51:33 +0100
Date: Wed, 22 Mar 2006 16:51:33 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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 Wed, Mar 22, 2006 at 07:13:31AM -0800, Alexey Melnikov wrote:
> I've already sent a comment to Arnt asking him to allow en;ascii-casemap 
> to work on Unicode characters. The advantage of this is that Unicode 
> characters outside of ASCII are legal and not going to cause matching 
> failure anymore.
> I though you agreed to this in one of your messages to the mailing list.
> 
> So, are there any objections to change en;ascii-casemap to work on 
> Unicode characters?

I would appreciate it, because right now the base spec does not allow
to match one arbitrary character.  To begin with, I interpreted 3028 to
talk of unicode characters, not octets, because the text was confusing
and nothing else made sense to me.  I just changed my implementation to
match octets for RFC conformance, after we discussed the topic to death.
It sounded like all other implementations already worked that way before.

Changing the comparator breaks all existing implementations.

If it was just for me, I'd say: So what? It is a change for the better,
having en;ascii-casemap working on octets stinks, using variables
"?" matches a single octet of a multibyte UTF-8 sequence (which is bad
and unexpected to most users) and progress sometimes has to break things.

But I am afraid somebody is going to say something about "compatibility"
and "violating existing standards" and stuff.  I can almost hear it.
Sieve is now widespread and since we could always invent a new comparator,
that works like "en;ascii-casemap" but on characters, perhaps you really
shouldn't listen to me. ;-)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFcMt7036195; Wed, 22 Mar 2006 08:38:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MFcMhn036194; Wed, 22 Mar 2006 08:38:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFcLvt036187 for <[e-mail]>; Wed, 22 Mar 2006 08:38:21 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 155B94AC1B; Wed, 22 Mar 2006 16:38:18 +0100 (CET)
Message-Id: <[e-mail]>
Date: Wed, 22 Mar 2006 16:38:18 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
Cc: Alexey Melnikov <[e-mail]>, Philip Guenther <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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 writes:
> I've already sent a comment to Arnt asking him to allow 
> en;ascii-casemap to work on Unicode characters. The advantage of this 
> is that Unicode characters outside of ASCII are legal and not going 
> to cause matching failure anymore.
> I though you agreed to this in one of your messages to the mailing list.

I felt a little bad about that and sat on it. Call it intuition. And 
indeed I changed my mind later. Now I think the most appropriate policy 
is for ascii-casemap to treat all codepoints it doesn't know as 
non-letters, ie. there's no specific tie to unicode. A UTF-8 octet 
stream encoding a proper word or pure 8-bit junk: No difference to 
ascii-casemap.

Sound good?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFWEAu035952; Wed, 22 Mar 2006 08:32:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MFWEjR035951; Wed, 22 Mar 2006 08:32:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFWCXH035945 for <[e-mail]>; Wed, 22 Mar 2006 08:32:13 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.133.12] (DHCP-Wireless-133-12.ietf65.org [130.129.133.12]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.5) with ESMTP id k2MFW9AJ029171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 22 Mar 2006 10:32:12 -0500
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 10:32:11 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 3028bis: post-meeting changes
References: <[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>

Philip Guenther wrote:
> These are in response to the discussions earlier today in Dallas.
> The log of the jabber room can be found at:
> 	http://www.ietf.org/meetings/ietf-logs/[e-mail]/2006-03-21.html
> 
> 
> Opinions on any of the following, whether yeah or nay, are appreciated,
> especially on the last point.
> 
> 
> 1. The first paragraph of section 4.1 ("Action fileinto") now reads:
>  ...
> 2. In the Security Considerations section, I've added:
> 
>     Use of the "redirect" command to generate notifications may
>     easily overwhelm the target address, especially if it was not
>     designed to handle large message.

These look good to me.


> 
> 3. IANA template

I need to give this some more thought.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFFu3C034789; Wed, 22 Mar 2006 08:15:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2MFFuaL034788; Wed, 22 Mar 2006 08:15:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFFtJc034769 for <[e-mail]>; Wed, 22 Mar 2006 08:15:56 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 22 Mar 2006 15:13:35 +0000
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 07:13:31 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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>

Philip Guenther wrote:

>Alexey Melnikov <[e-mail]> writes:
>...
>  
>
>>I think you've missed a couple of issues I've reported:
>>1). I can't see any text about stripping leading/trailing whitespaces 
>>(text moved from the relational extension)
>>    
>>
>
>Section 5.7:
>   The "header" test evaluates to true if the value of any of the named
>   headers, ignoring leading and trailing whitespace, matches any key.
>
>(This was present in rev -04 too)
>  
>
Ah, my fault. I've only checked the diff between -03 and -04. I didn't 
realized that you've already addressed the issue.
[...]**

>>Philip Guenther wrote:    
>>
>...
>  
>
>>>I've made one tweak for the next rev to the wording in section 2.7.1
>>>regarding ':match' and the definition of 'character'; I had overlooked
>>>an off-list comment at the turn of the year.  The paragraph now
>>>reads:
>>>  The ":matches" match type specifies a wildcard match using the
>>>  characters "*" and "?"; the entire value must be matched.  "*"
>>>  matches zero or more characters in the value and "?" matches a single
>>>  character in the value, where the comparator that is used (see 2.7.3)
>>>  defines what a character is.  For example, the comparators "i;octet"
>>>  and "en;ascii-casemap" define a character to be a single octet so "?"
>>>      
>>>
>>I don't think en;ascii-casemap is working on octets. So either the 
>>comparators draft need to be changed, or this sentence need to be changed.
>>    
>>
>Sure it is.  Section 9.2.1 of draft-newman-i18n-comparator-08 seems to
>concur.
>  
>
In another section it says that no comparator but i;octet should operate 
on octets.

I've already sent a comment to Arnt asking him to allow en;ascii-casemap 
to work on Unicode characters. The advantage of this is that Unicode 
characters outside of ASCII are legal and not going to cause matching 
failure anymore.
I though you agreed to this in one of your messages to the mailing list.

So, are there any objections to change en;ascii-casemap to work on 
Unicode characters?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2M39nTx004816; Tue, 21 Mar 2006 20:09:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2M39npO004815; Tue, 21 Mar 2006 20:09:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2M39mi8004808 for <[e-mail]>; Tue, 21 Mar 2006 20:09:48 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2M39kKS032633 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 21 Mar 2006 19:09:47 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2M39kKS032633
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142996988; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:From:To:Subject:Date:Sender; b=RdxqqPte7NwzuoHSGKC0n27QP DIM4nwmCY9joElrNIta8qJsIC034kC7OMmvwmM54UCUtu05Ut+x+FolVQ31K6SQf5sF Q/+bOeRHhtMt5n2grilbWBMECu7ze1MFaMtyPINWLm1xHQRPHpYXBV5u4FdmOZxcFY/ bNlv+LFeFhI4=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2M39kKS032633
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:from:to:subject:date:sender; b=MBeBun6VVkO5bIE35Ff1zAZrbPOGxCYWOxoiOv2nA5A4sQERSRXcIpb6p5bgGRa62 hot6ZTO3BYHXU9y+EcmIScHL62ZpEJ74DoVyO9CQGWKSjHe4rl8hrY7E2F48a1FZr7B olYDg0ydGss4Subdu4A6kvb2Zh1n3B/XXOiEe+s=
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 k2M39kaW089116 for <[e-mail]>; Tue, 21 Mar 2006 19:09:46 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Philip Guenther <[e-mail]>
To: [e-mail]
Subject: 3028bis: post-meeting changes
Date: Tue, 21 Mar 2006 19:09:46 -0800
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>

These are in response to the discussions earlier today in Dallas.
The log of the jabber room can be found at:
	http://www.ietf.org/meetings/ietf-logs/[e-mail]/2006-03-21.html


Opinions on any of the following, whether yeah or nay, are appreciated,
especially on the last point.


1. The first paragraph of section 4.1 ("Action fileinto") now reads:

   The "fileinto" action delivers the message into the specified folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.  Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.  If
   the implementation uses a different encoding scheme than UTF-8 for
   folder names, it SHOULD reencode the folder name from UTF-8 to its
   encoding scheme.  For example, the Internet Message Access Protocol
   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
   ends" would appear in IMAP as "odds &- ends".

(Hmm, need to tweak the line wrap...)


2. In the Security Considerations section, I've added:

    Use of the "redirect" command to generate notifications may
    easily overwhelm the target address, especially if it was not
    designed to handle large message.


3. IANA template

I think we should simply drop the "Capability name" and "Capability
arguments" fields, leaving:

   Capability keyword:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

As I see it, there are two major concerns for the registry:
 1) capabilities should be unique, so that require "foo" has the
    same meaning everywhere it works
 2) given a standardized capability, you need to be able to find
    the current RFC describing it

Concerns about different capabilities enabling the same action or
test are better addressed, IMHO, by reexamining the naming and
review policy for the registry.

For example, perhaps we should
1) adjust the vendor namespace rules to instead be FCFS registration
   of trees ("vnd.acme.*"),
2) break out a namespace for draft extensions (ala Alexey's
   "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
3) switch the rest of the namespace from FCFS to Specification
   required or IETF Consensus (c.f. RFC 2434)

I included (2) because we've had problems with extensions that saw
significant change after a long period of statis (e.g., 'notify'
and 'imapflags'), but perhaps the above is an overreaction.


Thoughts?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LLbWNb090470; Tue, 21 Mar 2006 14:37:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LLbWOi090469; Tue, 21 Mar 2006 14:37:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LLbVHP090463 for <[e-mail]>; Tue, 21 Mar 2006 14:37:31 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2LLbTpV021187 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 21 Mar 2006 13:37:30 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2LLbTpV021187
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142977050; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:From:Cc:Subject:In-reply-to:References:Date:Sender; b=S YUJDPy5k52n7RqCKd1WUbfXV4q+QbVJ5YUdPLwmEXpbhoJ/axAIaZ9OwHCF0x4mlVnC ZiOfgN9v1db5EhBEElbqCYKI07mbADL35f/XywCgyfr+dYM98HT7rrbUcXy/nBiZ7xC rgJe54KDfwtyooNzMlOzh0DXFKOv7NkHCAAg=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2LLbTpV021187
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:from:cc:subject:in-reply-to: references:date:sender; b=Dt0XA10NDLyz8uxqfBQLoRMK9u1NBmE4mAPCNFSAApwv0HW6e4NQ+he9O5on+0kge tfLnoTDV0luSw5FswFeQXCh1IwshfkOflg6aoZ3b85SLyxHxo5/6ZMfiNN6suSOSkiF waY+VbrxL2+d6rHGwcFsYEpwz41XMeScZvo6TV8=
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 k2LLbSff063536; Tue, 21 Mar 2006 13:37:29 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
From: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: document status: 3028bis, body, editheader 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Tue, 21 Mar 2006 13:37:28 -0800
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:
...
>I think you've missed a couple of issues I've reported:
>1). I can't see any text about stripping leading/trailing whitespaces 
>(text moved from the relational extension)

Section 5.7:
   The "header" test evaluates to true if the value of any of the named
   headers, ignoring leading and trailing whitespace, matches any key.

(This was present in rev -04 too)


>2). I think IANA template is not precisely defined, I am not clear on 
>what is the difference between "capability name" and "capability 
>keyword"? Is the former supposed to be a human readable phrase? Also, 
>what should be put into "Capability arguments" if an extension supports 
>multiple actions/tests.

Hmm, the template is really aimed towards new tests and actions, while
just about every part of the sieve grammar has been extended in some
way.  Checking the previously published RFCs, we've tended to just
register the name and ignore the "Capability arguments" part.  For
example, the spamtest and virustest registrations in RFC 3685 don't give
the arguments.

My inclination would be to drop the "name" and "arguments" fields.
Opinions?


>Philip Guenther wrote:
...
>>I've made one tweak for the next rev to the wording in section 2.7.1
>>regarding ':match' and the definition of 'character'; I had overlooked
>>an off-list comment at the turn of the year.  The paragraph now
>>reads:
>>   The ":matches" match type specifies a wildcard match using the
>>   characters "*" and "?"; the entire value must be matched.  "*"
>>   matches zero or more characters in the value and "?" matches a single
>>   character in the value, where the comparator that is used (see 2.7.3)
>>   defines what a character is.  For example, the comparators "i;octet"
>>   and "en;ascii-casemap" define a character to be a single octet so "?"
>
>I don't think en;ascii-casemap is working on octets. So either the 
>comparators draft need to be changed, or this sentence need to be changed.

Sure it is.  Section 9.2.1 of draft-newman-i18n-comparator-08 seems to
concur.


...
>>draft-ietf-sieve-editheader-04.txt
>>----------------------------------
>>
>>This has been reading for submission for a while; I think the
>>write-up is even done.  This last rev was basically editorial.
>>  
>>
>(Chair hat on): The draft needs to address the issue with 
>leading/trailing spaces.

You just mean in deleteheader's matching?  Or are there other places I
don't see?

I'll change the text in deleteheader to refer to the base-spec's
'header' test for details of matching values against patterns.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LJt6j9086231; Tue, 21 Mar 2006 12:55:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LJt6rU086230; Tue, 21 Mar 2006 12:55:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LJt5XE086224 for <[e-mail]>; Tue, 21 Mar 2006 12:55:05 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 21 Mar 2006 19:54:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 11:54:48 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: Dallas meeting slides
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>

Mark E. Mallett wrote:

>On Tue, Mar 21, 2006 at 08:59:29AM -0800, Alexey Melnikov wrote:
>  
>
>><https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
>>Look for the Sieve section.
>>
>>Note that slides contain a couple of errors (e.g. year in the new 
>>milestones (the right column) should be 2006), but the chairs hope to 
>>upload the updated slides before the meeting.
>>    
>>
>
>Re the page on the notify draft, currently page 11:
>
>   To do:
>       Need to bring back and update old examples using
>       denotify
>
>Does this mean that somebody wants "denotify" back?  Or am I
>misinterpreting the bullet item?
>  
>
No. This means rewriting old example with denotify to use notify + 
variables.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LIXF1e083314; Tue, 21 Mar 2006 11:33:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LIXFe3083313; Tue, 21 Mar 2006 11:33:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2LIXEIn083307 for <[e-mail]>; Tue, 21 Mar 2006 11:33:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 71302 invoked by uid 101); 21 Mar 2006 13:33:11 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Mar 2006 13:33:11 -0500
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: Dallas meeting slides
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 Tue, Mar 21, 2006 at 08:59:29AM -0800, Alexey Melnikov wrote:
> <https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
> Look for the Sieve section.
> 
> Note that slides contain a couple of errors (e.g. year in the new 
> milestones (the right column) should be 2006), but the chairs hope to 
> upload the updated slides before the meeting.

Re the page on the notify draft, currently page 11:

   To do:
       Need to bring back and update old examples using
       denotify

Does this mean that somebody wants "denotify" back?  Or am I
misinterpreting the bullet item?

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LGxeeO079460; Tue, 21 Mar 2006 09:59:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LGxe0F079459; Tue, 21 Mar 2006 09:59:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LGxdR4079452 for <[e-mail]>; Tue, 21 Mar 2006 09:59:39 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 21 Mar 2006 16:59:36 +0000
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 08:59:29 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Dallas meeting slides
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>

<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
Look for the Sieve section.

Note that slides contain a couple of errors (e.g. year in the new 
milestones (the right column) should be 2006), but the chairs hope to 
upload the updated slides before the meeting.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LGimic078737; Tue, 21 Mar 2006 09:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LGim1C078736; Tue, 21 Mar 2006 09:44:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LGikqt078730 for <[e-mail]>; Tue, 21 Mar 2006 09:44:47 -0700 (MST) (envelope-from [e-mail])
Received: from imap6.internal (imap6.internal [10.202.2.137]) by frontend1.messagingengine.com (Postfix) with ESMTP id C6F77D41597 for <[e-mail]>; Tue, 21 Mar 2006 11:44:45 -0500 (EST)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by imap6.internal (MEProxy); Tue, 21 Mar 2006 11:44:38 -0500
X-Sasl-enc: OyBXuCJ0ZCK+TKm0FPSHXzNmjWKYFIZx7f9O0qU4kLoH 1142959331
Received: from [172.20.101.119] (DHCP-Wireless-131-69.ietf65.org [130.129.131.69]) by www.fastmail.fm (Postfix) with ESMTP id E8D4C6D9 for <[e-mail]>; Tue, 21 Mar 2006 11:42:10 -0500 (EST)
Date: Tue, 21 Mar 2006 10:32:27 -0600
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Slides for the meeting today
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========AEEB27AEED0558C25DA0=========="
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>

--==========AEEB27AEED0558C25DA0==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
Attaches is a PDF of the slides we will be using in today's meeting.

As a reminder the jabber chat room is '[e-mail]' and the 
audio stream is: <http://videolab.uoregon.edu/events/ietf/ietf657.m3u>.

-- 
Cyrus Daboo

--==========AEEB27AEED0558C25DA0==========
Content-Type: application/pdf; name="Dallas.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dallas.pdf"; size=44026

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeNqVk1tv2yAUgN/5FedxlWoXDhdDNE3dsqTqtD5Ms5pnxyId
mx23xqvafz+wo6xF6SXGD1iG852Pw7mDH3AHXMW3QApSUOgtrGALZ3PPoPbAxuHruEQW07Jst26z
3y5zEx8kL0Sh4whRMppTSpEp1FIXUNYhAM1x/J3FyQ5Tt+RLCYjTxixOFJcgFYOyhbMly2lIq9zA
h5+Xi+sFXFWugaVrBtu77Q2sLk6g/A2LMmQ4IaXRWkupyStICEgmdsg4YVxSMFKkzMtFuQQlT+Fr
1TSVPyHPWQy5Usg1HMOSogg8FCRhrS5g/qtyvZ/B/LH/6wNz3XWnqR9Hg4Iy8YRJ3mQi5XyEpoLw
ubEP9hGubLN1f7r71JAjSiGUOsowVB2YNio1jLWLRfvu/DCDj234HLqZs8MmlRRMcC4o32PJe4qo
hB65qWTWDlW2Ge+MP3dtnXf9zafUVBTINBVHiyI1OhX9Vq3Xtp+Bd/benidyXBllDDt8achLbrTA
EZW6PT89etStYCj1waD5/4hT45N948NbjT8dpkFUmh7oe/JaOoYfTOehvb2NNXuS1T9+DxPCCmVu
ZHN0cmVhbQplbmRvYmoKNCAwIG9iago0MzIKZW5kb2JqCjEgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug
L1BhcmVudCA3IDAgUiAvUmVzb3VyY2VzIDMgMCBSIC9Db250ZW50cyAyIDAgUiAvTWVkaWFCb3gK
WzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKMyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg
XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9Gb250IDw8IC9GMS4wCjYgMCBSID4+ID4+
CmVuZG9iago4IDAgb2JqCjw8IC9MZW5ndGggOSAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VS
R0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVlJlLwTrYH
VwbtYB2M3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkEgpeQ
7Tczu+6I2oM37zO//7/fe0BdKG2aeoABecMWyf4ouzs+weo3UIcGBEErrVhmJJEYdplscWTtfYXk
nJvh4/X/XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFN
xRQUJ5AiHigpWSfmDrFsZDSD5JeJuzKWkicm38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwc
A1Y6a7LdpDsfqWndUjs7XJEUjAJ1P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Nd
jf3c4EJTmHNfCVFQNZ37Rnq82uvXi0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUE
HqG6bf7AzRMrmA+Fls3ZrEOWO1jYOTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa
7znaQW6MjtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQbejx
4QrDKMRvezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIVXsU4dHBoMOhr
gCGJfkQRhgmBAlTSaGShkZS7NoLYwuyxljoSPmak3yafbdfnHork7XjdQTSOhbaDCEz+Jv+Wt+Ql
+a38a7GlGKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5I6TVkSVp/qAny1eprzrVWGypRXJy8CfxPV+X
3JcpjGk30qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1emdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgK
ZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjcwNgplbmRvYmoKNSAwIG9iagpbIC9JQ0NCYXNlZCA4
IDAgUiBdCmVuZG9iagoxMSAwIG9iago8PCAvTGVuZ3RoIDEzIDAgUiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PgpzdHJlYW0KeNq1mE1T2zAQhu/6FXsMMwX0aUm9lZbOcKAzlMz0wsU4SjBN7GArtD+/
smMSx1GChVPCwRD7fbXPSquVX+AOXoBF1a+kGATHUBj4BRlcfi0JJCWQ+lMm1S1Crm87b+6bbh4X
F7r6oeiACq4/TuUcX2BMcMSEJArGiXseX9D62/PqonFJFuhqDJSunzuvLginChiOYLyAy+/kwv0H
xlMYfZmZbBKfwfgZrsduQGsHGmmMI147IL8DOAeCG4fqgmn3lTPpGDxQLm4yW+STVWLTPIOH0eN8
ZaB8MsaWn1xURfpowNjk4ewM7QyDRYRRhcmxQPeGQYWox4G64xgRWKSZM9nEinsKo018kaS++Dr4
sNBEM849GUKHB84Z8emvEwRXcfmUZrOOE9WSaC1RMCBfICNaASq3ScBh4JVQHV1U67aI9xarYCuy
na3oCGwiCeeUBiWzgt3Wbxj8NMu8sOBmaZIvlnNjzQT+5MXvU2H3WJ4E+67uMOxa6B7YKY6oVkyF
jBVV1NvyDYL7ZbywprTQ9WDORUoZtIyUmwkej0kRTy2UNrarsmsjuOSUReHp9Pi4MoOH5VNj1REe
lk9CMOuzjhSNOJFUB6+jHYMGw7fYGjjGfL2CgjaYGrnP7GEkhi+hjvBA5pTLHswJ0yLChAQvoh39
t1W0eownk8KU5f8B77E8Dfhd4YHgmSZ9JrtmUmCqWPhkbxtsdo2Z+XuS4iUJ9Tq8n9Dw4uXzOU1C
d4UHJlQw3mcluZA4JTp8JbX1N/l8Nom9LMx0VTZV7MCWsbFDval7/LZ7hnNBH90z9pXRAOyRVHs5
9GCX2nXpKrwL6OjXGG5vbq9hnufLsh9ztyx7MveYubZry9y5oI8x9ym3jjFhzKvWxXe6QB3mXEUE
06DR1sydfvdU9CO36TRN4vpk1pP6+2VsTd0XTod6M9NRIHWf8tk2kWHUdRQdOtOhFnXsyouIVDj1
tT5q67vDnDsAL03SlHR3Ji7Ma2r+QD6tTx5xEdu8KNvLd2Cr6g3zJL1qR3mv3K83XMkFoa7FDKoU
VX4oVnsDv42zeGbgPjWvBpZFbvMknx9pdIIqtM9wsy9+tFhU+6JX+KPFglKq+xQLJtycwTJ42lb6
3WJxkyXz1cQE1onGCB3k7YtkRISnTgRkspqZXuX2jhjyaosyyY68+0FvwInSBAsWDryt3zQ6138T
s6xL81OcTeZpNrvM67/jORTmZZUW5mSNiTe+kzQm+8q7jUn3LSj0ewvKhev3dGApJFUmBdk7yYxz
G88/u7NIHe/KmlZNvPsHt5+/xwplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjk3MwplbmRvYmoK
MTAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3IDAgUiAvUmVzb3VyY2VzIDEyIDAgUiAv
Q29udGVudHMgMTEgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagoxMiAwIG9i
ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+
IC9Gb250IDw8IC9GMS4wCjYgMCBSID4+ID4+CmVuZG9iagoxNSAwIG9iago8PCAvTGVuZ3RoIDE3
IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqllk1z2jAQhu/6FXskM4FIsmRJ
vTU0yWQm/QgwyYWLwSK4AUwsu9P++8gGEoxFsBrMwYB49t3dV2u9wD28QBCWb0ExcIYh0/AIK7jo
GwJTA6S6zLRcwsVmWXe7bvb2d95T5YuiIxRcXZbyArhHqw/d8mYLnS7hcgSUbpZ1yxuJGQpwCKMl
XFyTHrYiRjPoPKbZc7J6gpssLdYwzKO8MGcw+g1Xo0qMm44snezo5U1JZoIf0seU8XeaZWCMA0Ul
Jtwu2KpHbvU1PmPExf+WRbPcQLReZ+kfHX85Q7tY+A1/pDgE7/D2hskQQhLU8agzDig+lC8IwQHB
0oePuFJNPnQeommUJ+nqHB6iLIkmC23OYaAX1ZfRAop1HOW6UUAZMBkIgXwzFIwdKhjNtdEQWXcl
K8jnGgbXfbiKkzzN4L7QhYbJIp0+6xjSlW0ylZPE9HyqfGgSqUSjyk2TEKqUYFR64a1HUANvHX5z
14d+ulwvdF5aBFqJR64C2s43KujwCMUhVTKQJx2+zy8t4uIP19Ey1yaHbRC0s4GkWMowDLyMrhSu
R0GbKBunncPt96+/4HoRPRkYdzIdxf9gZq1wezW8GZ+dKh36wHuEhGGL0mFBGWXWKF7mrmrnCFAa
GeY2C53ZdMw8LRYxTDQ0EvvE2LBWlXtx0ZHESkdLGnLvsXHAr/K6TK38cWeZrGwKiTGFNpCnEMVx
po1xNwq13KCElaO5xRgPA44VIchzizoD/LSjJzOfGt+EyzZ9oNJ+x/6nD3V+JXs7EFuOFItFTdnl
A/70viABtTuDCP+R4uAPi0l36xWHi+LETAv7Sxfsc0hnn9wdktM2XeEht9NM+Xelzt8cCmrPzDaa
UV2zkm2mPKZCKYZpXTRq0xNHgLs0XddFI69CUzv/jolGez4SIVeMh+A7Xrd8tM//kebJLNkcYYxf
xaGs+bt4ymSrTSDswQs79i46Id7BH+hZYbTPpGyUPBDqY9X3qH6ah1On+U2aRBApFPf2lUvQQD/p
v3uKXgFg1cuoCmVuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKNzcxCmVuZG9iagoxNCAwIG9iago8
PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMTYgMCBSIC9Db250ZW50cyAx
NSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjE2IDAgb2JqCjw8IC9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwg
L0YxLjAKNiAwIFIgPj4gPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9MZW5ndGggMjEgMCBSIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42pWVTW/bMAyG7/oVPLYHp6S+LPUyYMUG7DjUQC+7
uLG8eGucNHK67d9PctImVtwmjmOEiKSH1EuKeobv8AxCx2/OEZRE2Dh4gBZu7jzB3AP1j5/HKSrf
Tcv28+q35Wpm44ezdyjYP4GS4QwROUmjdA7FPKzHGe9Hs2jsvcyX7HMBHHfrsmgQN2E4GMUSbr7S
LPwDRQ1X9+ty2TnfXUPxC74UISQ85bI3LqRcjqTHuNkB2ActpNVoc8k+CHoEbsQY/LHxEc/ei3eI
JLlHRkNgGLIyJf7gUl2zQcTINZIhZSbxpaTIZwn/brvZuLaDalPW3e3u50QibbW1ZM7pP/BHSomx
DTWuqxM+cqulDDtiUzZEubBjDjLfuBeX+X39hJRkyA8STs9KbvXQB9tlZbgJEiRyUnJqUtgJHq6+
eb91/vbD0k+o4Xwii9RgSKPB5uqklATHVHkVYg5HQJ1NLX+NOjYCa8f494vV9qmCPw4W5YuDx1W3
gNcsQFrDRihFl8h17DgcOxM9p0VcthUc5fvT5cKxAT8KR6GHXaAchWwjHvU6dkH8Ubgx/oOD1rkK
uhX8dm6damUNGiuMmqRVKC/qnaViHXLS1NAtXGjpZXjd38Z3TfvzsM/0Eoh3BDt/CVhJKC2JScr3
ynBLqTKVWz+t/i1Dh/Kzo8j+A693hmwKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iago1MTAKZW5k
b2JqCjE4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNyAwIFIgL1Jlc291cmNlcyAyMCAw
IFIgL0NvbnRlbnRzIDE5IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKMjAg
MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAg
UiA+PiAvRm9udCA8PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKMjMgMCBvYmoKPDwgL0xlbmd0
aCAyNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjahZDNbsMgEITvPMUcmwNk
WaC2e+zfPRJSL71EBkuulKixoyqPXyCWI1euwiKxYnc/hjlhhxPMY94VE5wlDBEfOGL7Mmq0I3SJ
sc0trrq2yamvm8edavJi8Q+FSiQKKSLSXDtyDXybxklxKcqcTI+0Bzx7wXQdkznRpnIwKfEHbN+1
SjfwHR5e9+eIDfwX3nyRs8IThYclryZWDVu7Ch323fkGpVmpWFUKbSdyTgylUmP/Mj/ZuhtyJ5bG
4Z5xsjjHzMS1cQvrxB1B1uo1QeWTTwj5kN0QY5BjH3+iDMlS2R9DvMhkjUS8fPdDDBsxi/8FACN/
TAplbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjI0NgplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUg
L1BhZ2UgL1BhcmVudCA3IDAgUiAvUmVzb3VyY2VzIDI0IDAgUiAvQ29udGVudHMgMjMgMCBSIC9N
ZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagoyNCAwIG9iago8PCAvUHJvY1NldCBbIC9Q
REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9Gb250IDw8IC9GMS4wCjYg
MCBSID4+ID4+CmVuZG9iagoyNyAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PgpzdHJlYW0KeNqVk0tvgkAQgO/7K+aoB3DfsF6a1LSnXkxJeumFx1JpFJXFtj+/
u4giqLWyJEzYmW/eW5jDFph0b0AxCI6h0vAGJUxmhkBqgDTHpE5FBHs1r9XLj+bCV+6h6AoFN8dS
sI8xpgpjqRREqTXHPm0uPSe0TtIVPEaI4r2Z5wRizYBZIVrB5Jn49g9EOYxed0mcZZU2BsYQfcJT
1AQ1oKIjFfpUJblPBeOX0EyoMClMh7UaKfojYiC8ZTuBYXul+JD6TrlokWjuGK4gEpOQiPBGRfp8
zkmPj/b82a6qdFlDVsV5Pd1/vC6HxiGTytafXPeHLvgjQrBLCRW6zgd8zEOsWCj5XQUjAVOXHHim
0F/aq/K07YiH6RidNgXuakqgZN8FOm3KMYeQEB5SdW9P0BkeRi+xqe1KrOKiLMoPKIzZ6Sks1t+Q
L/VPkSw1mMV6t8ygneVuQIYbBrc27BA8Y1zaIA/Ro39OlJJn9d/ElbFhT8xmWdS1SyDRD10D5r/c
P/dACmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKMzg0CmVuZG9iagoyNiAwIG9iago8PCAvVHlw
ZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMjggMCBSIC9Db250ZW50cyAyNyAwIFIg
L01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjI4IDAgb2JqCjw8IC9Qcm9jU2V0IFsg
L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAK
NiAwIFIgPj4gPj4KZW5kb2JqCjMxIDAgb2JqCjw8IC9MZW5ndGggMzMgMCBSIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+CnN0cmVhbQp42pVXTW/bOBC981fMMQFihaT42Uuxm2aBnhZtDPSw3oMiU5Fa
WXL0Ubf763coJbYiy7ElBwgty/Nm3jw+jp/hCzxDqPyf5hSkoFA5+AYF3N7VDOIaWPeqY/+I1P1j
i5fnkv3XZWD9xcmJKLR7YZQFDSilNtSSchPCMsYANODdxwu/eIGJN+TPJXDef3HhF4xLCyFVsNzA
7V8swDuwTODqq3tyv+Aalt/hfokZ9RDMhoxSoxGCnIKAIwiD9ycgPlVR0ngE0iHQ9/L2QdlrUL/w
8aSS45grLuQ1eZu0ttLS0MhZ8YVgPj4Zxb9rq8oVDax97h/6f4sRS4xJqSjTx3jkNB4LbThVUOaa
ZFFn7qcbw1AZIpRljMypC5thp3Aq3+8FpQfy+oYraYQyenZvjGFj7v7eumKgqIvDSasC1JEgGHOc
9ue6bl394RD1MhWRQaaMhnZSRiO6hdRScWFmtdXLaApgmTrYRN/LCkrPSubLgF3WpNCkWd3rCu/C
Lo0aaEpYlzeQJSNlM9y8oTZ8trAZU3bcnaj4jdDF0w1Ej2XbQF7GUZ79FzVZWdxmReOqolvvbwZ7
gsh50ulrBrgQBkmf8INVyOnR3jWKc6PsLABpbQcwLvEP9M9/Pt/f3wf4VLjgAUNz/RfiMs+xouIJ
avfcuiJ2NUTFGuI0qqIYCz94VE+7VIJrbebnJJjAoskwJ0TMfkY5ekoNdZskWZzh+uOFgiaT3Eox
ze1I0JYqESrZnxdkTh0TAA9p2eZr2Dk8pBJXeRZRym7cTyNMaDmfRR3yrTvMcT+hLbK4XCOQi1Nc
RjnUWxdnSGKn0PdZJGcUqnyHz7NotLB4wFkyWw0TAAcWty2eMl6F2/Yxz2rvCw5dIG43/viJanC/
tq7K/Lso/zhw7dlOzUw4tFVyyv+YUEzTcNZRQDq3eQswKjTK83IHdVpWTYr1+l0Qp77AFV6PsLra
ldUa0JKKdVT9Xl0fOQQToURdzTdBq+ixCa5hKBoaKNpdfLh8nbgYRReg+uz+GSLjlgssM2jaHv9I
YHjtDhVq2PXD3t3DyWQe7k6XrYQgzGodSNiAtgZe3uTw0Jc3HB+VFhSng9NjEpkoR1s9Wchr3/Ye
uroe7kYyV6ScMXPJrCdxZ9GQ69lq8ADkjEgfo/jH3t3qo+HY8ye6c+394fgNNqf8RHVXbe2SNocE
h4RN1MT+cD6UO/6NAJf9RhCC+yT1rBw7frrJ522K6xK9CccWbHR9A66JA9/lQ4r/A0ah/RIKZW5k
c3RyZWFtCmVuZG9iagozMyAwIG9iago5NDUKZW5kb2JqCjMwIDAgb2JqCjw8IC9UeXBlIC9QYWdl
IC9QYXJlbnQgMzQgMCBSIC9SZXNvdXJjZXMgMzIgMCBSIC9Db250ZW50cyAzMSAwIFIgL01lZGlh
Qm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv
VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAKNiAwIFIg
Pj4gPj4KZW5kb2JqCjM2IDAgb2JqCjw8IC9MZW5ndGggMzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+CnN0cmVhbQp42p1Wy27bRhTdz1dceJUAFT3vGXoTNI8CWSRFUgHddDMlR9IEImlzRnby
970k/RzRtlhREAmRPOc+zn1cwTe4AqGHr+EUlKTQe/gbWjj/EBlUEdh4xGp4RJnpsdXtc5v711VR
Dh9OnkGh44EoK1pQSpnSXJWcw7pCAFrw8fZquLilqRryfg2cTi+uhgvGrQKBF+sGzv9gBf4D6w28
+e43h+jhY+826S2sf8CnNdpFH2GTHBsQm8lb7OFCULxleQ79D5fqAXKynWvKLFOWvGD7Eb6UbA7/
w6HvfZugHmy/mE6rt+QJodClLktmYQkfU0oMhCQjDD5tcoe0pNJo8Qo+eYpvRDnn0CoGf+1X/ZgS
PP3wVVpR9igtY/q1slJb82oI+R0ln1JkpMoZ/7z0LTyE7GQ4VeqCcyqPMcmbzzEefLyYFxOcJKaS
D6jkNTEpyrjS2pyAT56IacJ/Eonf4cb9gtRB1bWp7/ZwtvWt713C2vjrK4QNpJ3HwnSxazONUWOs
4HTAXChqRo3ORRZTH9rtaIYLbYS2a1eZ44wpU7I5v8mLouYjYe65i1UIZ3AdC9i4sIdJd5AXkpTK
WlYu8pFrTWedvI7/Vx7cWEXm3CjyINFSCybMosock8K5zcHPen+5d5WfzYZiQluqF7U0xkoxyzRm
A25C2kHsGp9lgWG/EUYtUxqnmo9ceRZgIqt2rndV8v1ZcXpWyFHRMsnECSOAUWrLwaI7fHJqsczg
f5+0Glq0Hl0IXTuGLosax5alpNXLhoBhcuQ8ipqvkcK72vd5QyqxM5dWPa85MpceIeisc7+BT1Xx
7nk+ho5pyZcPU9wgZM4W3a+IPc4l+PLxazxqcaU11Ci5LIRC8pErD+E5ttSYB88Iyq3QZuEoZXrW
HYi77rCvURrV/lD7sXsfLmvs5/U9MbkdI0orzJpY3r4Ne5gjZOJtfIxu6wv4PEQzRGynV4fQ+2bY
VFLXAfb3rt2+e7HSyMvjkZXHe9zcfLSS4+oj2XJ9zBBcu8qNBZb8zwR4DsziT3O5Dz5CSNCE7S7B
vxjmiAvMHp3NRYRTS+LuyhcHGsuX5RpydQ0OLprQYHLdFjZdPya5crjO3uxwr0GRnaOWITyS2rRy
k/uVG05auZmWErcuvShTo+GcHpX13V5RP+q23/4DP0HJHwplbmRzdHJlYW0KZW5kb2JqCjM4IDAg
b2JqCjg3NQplbmRvYmoKMzUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzNCAwIFIgL1Jl
c291cmNlcyAzNyAwIFIgL0NvbnRlbnRzIDM2IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+
PgplbmRvYmoKMzcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug
PDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKNDAgMCBv
YmoKPDwgL0xlbmd0aCA0MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjapZPJ
boMwEIbvfoo5NgeTsfGCe2yUSpWaQyWkXnqJiImoAjSGtq9fm0RJAzSLipEY4/H3z2Jv4QW2EKvw
ao4gBYKz8AoVTGcNg6wB1o0mCy5S79zo3i8/bJeRCQ8nf1CwG56CESIyYVCgSSDN/H6MeLdKg7FX
yUrykALH3T4aDMalX/ZGWsL0kUX+D6Q53C2eFnOYQPoO87SLZ4RHshIGvESoKElQj0Gf6/qjOULx
ECkZRhrITOzJwYjRLxnRZ75xIY9I2lWCK2QJkwk5U4kBXwg2xp99OmerFlZumbf3uw+dkBPBWBll
DDtb+YEekzIOgqQnWNg27yekBTJ/BuQFAXIqoGMzlhFtCvtlaVmUlm58Ryjif3qijbqmJ0IqEWuh
b+7JCH9h3do6qHNov2uwS7cp/LRrTQN57SDkBq1t/HRZrY7d6l8suOpicca4ltL40pCbQjdqUPxQ
8KJaR79i+gEirO6gCmVuZHN0cmVhbQplbmRvYmoKNDIgMCBvYmoKMzU5CmVuZG9iagozOSAwIG9i
ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDM0IDAgUiAvUmVzb3VyY2VzIDQxIDAgUiAvQ29udGVu
dHMgNDAgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago0MSAwIG9iago8PCAv
UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9Gb250
IDw8IC9GMS4wCjYgMCBSID4+ID4+CmVuZG9iago0NCAwIG9iago8PCAvTGVuZ3RoIDQ2IDAgUiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqlVlFvmzAQfudXnPq0SSW1jXHsvlRbt0l7
2VQt0l724oKzeAqYYqdt/v0OQpuGUBq2JFKcYL67++6+z9zBDdxBIprPnBFIOYHawE8o4eLaU8g8
0Pbts2ZLOt9ti7t9y+fb05lqXix6BYW0b0SJyYwQQinlKWcKFhkCkBlrL8fNoguTFdHHBTCyuzFu
FpRIAgkuFgVcfKEz/AcWS3j3zQW7tJkO1pXwqdbL8B4Wf+DzArMjbYRoOAJgBMq6CM0iIXhJpP0A
vxhPO8jopqtACCWwgmSsgiN8zukBfrTDv97UtSkD5E3u/rKf/Rj6Ez+4iLjE7pDkKPuEkT1kmz2V
jDNG5Kvw0TE8pEoNwbdJx9aEZeytuTdx2bRjGxO2p2xSHdDUIRM+WEd0WIeQRFGiJsE3dSB8dGId
hbbr4GJCRtsSjZejhDilLUoymSgZTS1nAP61cnoMEpoovDuVkyikXKVN0D6Hj0VVHTLVhkB4LuT8
LbEfSRFdQvXr+l6ZEvYBRqf3JV6qxAxHng+CfvV+Y4aFF51oG5TN5yO+8cw3FxydT4loqm8MBfhm
TA4aHvQWggPzGGqdBSiM9/q3gVuXb89Bewir3Y9mhyk92mRfRyRJGJNssplRTo6GwFcma/14vd5C
bj1+u4cmCR1mb1lbNMZwKvhJDHPCSZqo6QwPBPixcpt1Dg8Gqo1ftUze4ai0R41bgqlrV+NZl7l7
U7dNwB19ctGlWOv6U/MR6silbJnbe5tv9BrbHFYu91cnHhfDCpMpO4VTOZ8LJRWfdJq2NQwEOKtq
62obtmeArHkNZ7aoXB10mb3gjkzii87RBnvBos5mkzfs4rWBY6iL/lE9RE6KE0cI4ycmHD2TcxCg
I+dDnkNAnYK+dZsAflNVNeq5mzeb43NCIy0oXzz0+HPAKbS+7+0SZSDQbyZPHqONfA4TCyuLInYO
5y5b6dL6Ap6UfvU/smZMyfER/MdnTMWlSgRNJ4mirX4go91TwOUB7Z0CG4ctdJnr4HYWgNO8NgU2
6mrfkJu/TBqkzAplbmRzdHJlYW0KZW5kb2JqCjQ2IDAgb2JqCjc3OAplbmRvYmoKNDMgMCBvYmoK
PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzNCAwIFIgL1Jlc291cmNlcyA0NSAwIFIgL0NvbnRlbnRz
IDQ0IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNDUgMCBvYmoKPDwgL1By
b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8
PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKNDggMCBvYmoKPDwgL0xlbmd0aCA1MCAwIFIgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjapZbLctowFIb3eoqzTBZ2ju5SNp02bWaySK90
uunGMSI4AZvYounjVzYkgG0IppgZa3z5/qNz9RN8gyfgqv5rhiAFQungF+RwcVVRSCugzVGl9SNS
rx6L1s9NXl+Xsa1/jOyhYHMESoQxIqVKcikNjNLwPsasuRvVi7VKOicfRsBw9V5UL6gwHHhYjOZw
cU3jcAVGEzjjyMxdVp3D6AE+jYJF2MWSVywELBVrbL3gGG5Z0ab+ZkJukI3VyBRSQ6UhB8zu8IWg
ffyrZVm63MO4TCb+cnWKzsmOIFdWWUsPuqmjR6XktSBpCWbOT7Z8VO8HhTwKTV7Qmtu+vURV5v64
aB2ICNX/xEJbdVQseGBopQbHoof/3c0S78YHY4FUSM6ZYMODERTbwcjd8zzJo4yaPEqL+SIpE1+U
EZr2No3mRjC2USVHqNZupKxbKV8WLoebqlq66rIWIvtC9BZbINtlk94YhXwJV4MHBgiQOkZdATi7
deW9C23lwaUe7pL0EbIcnjM/Be/++mUyg3Sa5PeuAl+sDSEvhgjkITmZgqHJQqXeeJGsDFm4cp55
uP34uYJ2QSkxrKBY6IE7GuvNJvl4i32AR3bTTVgZMyVEL3RRFr5Ii9le8oHKpNaq2Brdb+4slP8O
lhzpY8ZRxAyp7cWugp0V+aYWT0hWrbdziexvKFYjZXp4su4KNJb/mBbL2Rj8NKtCyoYKn7t8fFG6
p2UWBqOfJr4lT1EZxDA/h2wv7KJfHibZzGW5L+BUzzHLZK/r5smiYzpDwdAMd5wVnZD/HF1HZlPB
LxpMKMa51oOmiVWqVwPmQaVduXzYVKdci154pLd8PmBOMBkrG5zYYjY+f56Gvn1UO2hRjRIxUs4b
ansGPRflY5bfnwAmjCsZa4661wVNUz6aSjY5p4SNNWrZS03edAHpy2NDQ9+i0vQyb27ff91AT/uW
RW4VC41cvfUx2xkujNZFs2tRFT4D3Lstm/4BmAqLWwplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2Jq
Cjc0NAplbmRvYmoKNDcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzNCAwIFIgL1Jlc291
cmNlcyA0OSAwIFIgL0NvbnRlbnRzIDQ4IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+Pgpl
bmRvYmoKNDkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg
L0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKNTIgMCBvYmoK
PDwgL0xlbmd0aCA1NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjapZLLTsMw
EEX3/oq7pIsEj2PnwQaJqiAkukCN6IaNlboQwEGNA9+Pk1R9kYpW2JEyyozvPZnxCo9YIYrbJxEc
SnLUBnNUuBw7QuFA3XZFW6KSvixY1y03x1WYtUuwIyq8214l4CH3S6bIC3+Wh6LLBG2wdigsbnII
wVmX8QGIJwkioZBbXN6K0H9BvsTFVFf6xczuJ0+TEfI3THJPxH9Lsz1pkj1O0AYR96lM9sq0UX4W
Um0le2pB5BmkZH+g7+lLSUP646+6NlWDRa2XzVX/Cqyum7IKRmzPV5DgSpLAObaUxar1ZQe+tuuY
K8232emYd6FI+Z+j6KgLG3ARcTrYvYDH/5lHlqUnzIN4lHjs9OxxDMhP9btB81o6aMzvUDbGXmNm
jHX4KH3qwdjPSi/MdjSHNx+n3XyZRYorkfiesLOgieL4kLoyZuE8bLiD9QMHM9nvCmVuZHN0cmVh
bQplbmRvYmoKNTQgMCBvYmoKMzQxCmVuZG9iago1MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy
ZW50IDM0IDAgUiAvUmVzb3VyY2VzIDUzIDAgUiAvQ29udGVudHMgNTIgMCBSIC9NZWRpYUJveApb
MCAwIDc5MiA2MTJdID4+CmVuZG9iago1MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg
XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9Gb250IDw8IC9GMi4wCjU1IDAgUiAvRjEu
MCA2IDAgUiA+PiA+PgplbmRvYmoKNTcgMCBvYmoKPDwgL0xlbmd0aCA1OSAwIFIgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjalVXLbqMwFN37K+6yWZD6gV/dVJ2qlbKopqNB6qYbB5zG
owRSIJ35/LEhSsOjFfC0wD7n3nMul3f4Be/ARDgkxcBjDKWFF8jh+r4ikFZAmr1KwxQu22nRad7m
vJwvddgo+gIFN7tHifASY8yVppgSSFK/Hi9p8zYKgxNLukc/EqC4XReFAeH+wvyZ7OH6kSz9E0g2
cLXK090xswtI/sBD4iPCQ1h0hgUPS+ITbBgw7F/puI/6SmP+CdlGTQUminCFvgl7gB/HZAz//liW
Nq8hK82mvmlv0QJ1CbmSmknNYQ4h4ZwFRtRjzMy6KKLK2Q8buVazCLN+jppyrSjrWoMm5CgFG2h4
Zf8dXGmz18WZBuFZyQR3tBh3pyeW4thXR1B6pjsev6/Vy9bUUBeQFfDX1Vuot666/bbCuoU7yIEQ
IaaUmKLePYxZQ4BmJDFG8Hxc71y1BVOBN8KWbu8rzuxuB8pJpmJK6WxnCBOqL93Pg81hVVVHW91M
VOyEjbrYXOIpignuv0rB1eyCHSNY5bUtTVq7Im+N/zClM+udz8U3r+Lg8rdQFhvnn1zIOL+miZT0
ghx9kR3xh2JqDjxqcuvCj+fWV5JIoRSO5ZkNTek2TPBRuieTmzf7O7QbOJRFXaTFDkyewerp7vlT
uv4PBKb9QHxbjLUmoU2hWR870fHA9TbIpgVfBPYfN+KaIgplbmRzdHJlYW0KZW5kb2JqCjU5IDAg
b2JqCjUyNQplbmRvYmoKNTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA2MCAwIFIgL1Jl
c291cmNlcyA1OCAwIFIgL0NvbnRlbnRzIDU3IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+
PgplbmRvYmoKNTggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug
PDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKNjIgMCBv
YmoKPDwgL0xlbmd0aCA2NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjalVLL
TsMwELz7K+YIh6R27DjpCQkIEidUiODCpaRbGtQ4bZyKfj52WkIfAlo7klf27szsZJcYYQmp/ZdE
HLHiaAgvMBjcWIHCQnTbFj4lTjZpwTZv2pfH4dCviP2CwrvtUAIecrdUgrxwtTyMupfAB1uGosJ1
johz1r24ANpzuDOvMLgTIXeK8ikusnVBi7asjR08dOd4jkdarsqGLpF/IMudQFdVsL+YhNqoC3wg
uXsaqkOm10jFW0g22jahEp3qNP6vkT14pcQePNvA39b4JBiiCWxdOWPrpkI9BX03iNnYTOaleUdp
flrrdAiexjI5q0mvItHysMmn++w5u/LwrHcOZzknhNb7qGzXOvTWpclQunE5h4B51ccETvasXs0n
aGfkhu6NMEZLtvUe+jssGrJkCnJ+/vzBw7nFaXObylRprnrZ7ESzhZRHI0Xrloz1w7tj+egLqQPS
2gplbmRzdHJlYW0KZW5kb2JqCjY0IDAgb2JqCjM0OAplbmRvYmoKNjEgMCBvYmoKPDwgL1R5cGUg
L1BhZ2UgL1BhcmVudCA2MCAwIFIgL1Jlc291cmNlcyA2MyAwIFIgL0NvbnRlbnRzIDYyIDAgUiAv
TWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNjMgMCBvYmoKPDwgL1Byb2NTZXQgWyAv
UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjEuMAo2
IDAgUiA+PiA+PgplbmRvYmoKNjYgMCBvYmoKPDwgL0xlbmd0aCA2OCAwIFIgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4Kc3RyZWFtCnjatVpNj9pIEL33r+gjcxjS3x/HZJVEGWl2FQ1SLrkYMLNEgAmG
0ebfb7fNh23K2MXAgDSWgH6ueq9eVzX8pt/pbypNfFrBqFaMblL6g67oh79yTic55cUjn8S3aFu+
7XH/vtnx43ro458gLauw4hFWeWRDxpjkxjGrBB1NwgJsKIqXH+PFHmayJJ9GVIjyg4/xwllOJTN0
tKQfvvAhC7c1mtHB83yR5ttsleb0kWZv6Wa6Sx/o6Bf9PAq3x+PnSQBml7BowOJsjxUvIo5yvon1
Uyj9QA5rl7F45oV3VqDWV4rH9Ulz/cHH3SsVjOmfD6cY6smTwiqrhT7HI+14nmkoHvqyGy/n2xNU
gcCFdUoQTDxccAcCpNP59t80maYb2kycUQEoKAGVuCAcBWVuuklmW7rN6LfPL1/rqePH1IUFhOGi
ThXpQBROwFoYPCd/6lyRvd7oVXozgh8xSEVvtKE3o4w2rq/eyFFv1fWPMbyk6w69MW+9MtYalCCc
40MjjYdQ96oLHvE2z9NpQxdB355Z6XGy0KyAasqC5utkuQ3+QJtp7FQfgWDCnUERdaiP7MtKSWUt
Kq5CfJAwBh/XmzPiUOIjNfFZLUGza2bNc8mCHlAVFMUHrX8uPnImPsu1YVxJihWf50w4AsAe1CfD
6+N53tczCJo2MOSKZ5CraKt7hnNhH1iSDto489oLrlGqiKyVyzdC+Gey7bAM7rXkUnucY4TSAPAu
mwW3TjqN9goZkc68YpO+pv81jYJ7IR03pqtVqUNYq6FgCp9oUxrTVrMgXYWXGsjT0251S6nxkOx7
am2/PlpszBltuWUWrTYIkf74ShdJ2C8myWJBs9lBdzTfjZPpdJPmOS1ZJC1+IaUJHGpMfklBIpyA
5wTn86SDRa58D6M/sEiwTS24fpVFgu1qL6StIBEAhNtaIYMlSa5ACNJmFmHLhzHmy2Q9WySveWtr
geugjZQgUL23aFMdvrfYiw7kC9tcdIlOOH5X0UHr9xAdj+xa7/CiAwBPG9Vsl6e010DCpFRhs/RX
WD4c89NucVPPV1z28HzMDNww/RKgEcXf2ds9Oow4BEOAl1sMZgwPD8+RTYYsozufSBobSWcDeixt
glQImNtKad9EIVqp+yqkBMArJL4sjMMrBAA8KGScTf/QYpzs5crHju4KXwbDrrR0N/FlY02fqe9A
Ht6YIYAqeW3GLKQxTuK6gYI8APA46c1X23STrUOdr7NNext+VbQlaWC4lSO9m1ScY+6+FVcCoCuO
eefjRMbxJQcgAo14MZ0R9HR27s2O+QKToMazw16N6h9LXYAZrezV1WIm1+rCK1YHIe/Vxam2Cl2c
AfR0YmWM8L4EJBhZAIB1WcyyDV1koaQvjmTvsWEw5hvbsGCRjTvaMAjQx4ZlwDRcoG0YAjxnbpVt
57P5JNnOsxVNJsW/agkSXAlesmYCp6ClBC9ZM7lEpGCqF5EmTLraGDyREMDgKSnkaNqJDNbMnfIO
OV4bNfTSMgviHnqiU/11HYBfT1/9Bsg76Lt0Bi6kNL3GVCutdRJ9Bg6uX2Wv5RCcSyGkNbhTzkie
E85wAsHCJyTMSROfFvelCLcejG2/ZVcruyoRAll1bPvCTM6vqHAwu9D3W++pcGVcrwr3cQBEnkkW
GoEABl/ScWeFhy7IOtwWV3xJFy40CHso8FabPiez+XMAeuHnAEDHjeoQSl8A0wV13N//Bzs8GV8K
ZW5kc3RyZWFtCmVuZG9iago2OCAwIG9iagoxMjkxCmVuZG9iago2NSAwIG9iago8PCAvVHlwZSAv
UGFnZSAvUGFyZW50IDYwIDAgUiAvUmVzb3VyY2VzIDY3IDAgUiAvQ29udGVudHMgNjYgMCBSIC9N
ZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago2NyAwIG9iago8PCAvUHJvY1NldCBbIC9Q
REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9Gb250IDw8IC9GMS4wCjYg
MCBSID4+ID4+CmVuZG9iago3MCAwIG9iago8PCAvTGVuZ3RoIDcyIDAgUiAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PgpzdHJlYW0KeNqNkEtLAzEUhff5FWdpF5PevGaalVBR3MlAwI0bjamt2JE2HcF/
b5IZK/SBzc3iktzz5eRs0GIDVefdSILRhG3AIzpMb6KAjxClos8jphnGqnFusZcbbvOS7AyFSiUK
cSJSpKw1VsD5pCcuy22Vm/EVv2ZzB0mDrsqNEEmgUuPWmN4Jnk7gFrh62C3DFhO4d9y6YugAyAYg
joC1bbjSyp6izvu46kKMf9w04tk5txku5AjPjaLh6gD7JLUZkaw9Sg//pVeV+JLvejbTah8fu8CQ
1uKUofvnr4Dvzx5x9daFV6Qw8fLRB8RlCLvrCfv9fvsDOTN76AplbmRzdHJlYW0KZW5kb2JqCjcy
IDAgb2JqCjI0NwplbmRvYmoKNjkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA2MCAwIFIg
L1Jlc291cmNlcyA3MSAwIFIgL0NvbnRlbnRzIDcwIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEy
XSA+PgplbmRvYmoKNzEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh
Y2UgPDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjEuMAo2IDAgUiA+PiA+PgplbmRvYmoKNyAw
IG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA3MyAwIFIgL0NvdW50IDYgL0tpZHMgWyAxIDAg
UiAxMCAwIFIgMTQgMCBSCjE4IDAgUiAyMiAwIFIgMjYgMCBSIF0gPj4KZW5kb2JqCjM0IDAgb2Jq
Cjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDczIDAgUiAvQ291bnQgNiAvS2lkcyBbIDMwIDAgUiAz
NSAwIFIgMzkgMCBSCjQzIDAgUiA0NyAwIFIgNTEgMCBSIF0gPj4KZW5kb2JqCjYwIDAgb2JqCjw8
IC9UeXBlIC9QYWdlcyAvUGFyZW50IDczIDAgUiAvQ291bnQgNCAvS2lkcyBbIDU2IDAgUiA2MSAw
IFIgNjUgMCBSCjY5IDAgUiBdID4+CmVuZG9iago3MyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01l
ZGlhQm94IFswIDAgNzkyIDYxMl0gL0NvdW50IDE2IC9LaWRzIFsgNyAwIFIgMzQgMCBSCjYwIDAg
UiBdID4+CmVuZG9iago3NCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgNzMgMCBSID4+
CmVuZG9iago3NSAwIG9iago8PCAvTGVuZ3RoIDc2IDAgUiAvTGVuZ3RoMSA3MTUyIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42r1Ye3hTx7Gf2fPQ07Iky7YkS5ZkWZJl+W1sbOzYwkjG
BkyMnaQWxcQPTIwDjSHEBRpSJyEhMY+bhgIptElIUgLmUoShQYTCpbmkhK9p3k/a3jQNSdPcuLmP
0EfA0p1zZAj0o735o1+12t2ZnT2zs7+Z3bN7AAFAC8PAQbB3Wfcg1MPL1PIi5YHeoZXOTb+vWwmA
VQDcwOLBW5btO/LJOAD/FIBy9JalqxeLg5/YAFJaAVQ/6e/rXvThXy7OB8jU0vOV/dSQulzYRHyI
+Nz+ZStXlaziHyO+n/i8pbf1dmsfVtcR/xDxGcu6Vw0q+1TfJX4P8c5vdC/rW3j73SPEv0B8zuBt
t6+EnXgj8Z9K+gdX9A3y92aJAOZcsu/n1IYgzUeakQgLqQ5D/mQLAJusOfjyx8ulANf6iZO1grLy
KomKHjkJeuE45AnDYOWLwQGQeJfyWamO35j4SDgN+viyxH9zNdT/qJRZvL4WTsIm2AkHSPceovPI
xkfgDA7AUVwAh+EtzIYi8gUPMZgDL2Ii8Soshqeo/0p4DrbCQZpXHiyDdJJuRk9iDfFBontgXeIJ
yIUquB+OQzVp3Qzjib2JQyRtgxthFPbR8z9HNzvIpyV+lDhH85lHOteR5NXEnMQBMEIBNEArta6D
E+jhzib6wQw1ZN334THYBT+FT/EePJzoTwwlXkm8T1iawQbtlNbiYXyfO8Dfn/h+4pNEnJDII8zb
oAu2wJOk/wClk+SWMN6KK3ELbmVBdg87zN8nZMYnCAc/zKTUBLfBA4TAUTgF/wN/wc+YmdNzK7nn
ExWJ/wUNzKZZSjPpgyFK6yltpjkdQxFLcAa24lr8Lm7F11k+u5F1sG+yVewjbi63gFvNvc7fzo8J
G4VHRE38fOJY4nTiTcgEO3wdVsBdNLvn4BX4HL5AjnTZ0IM12IALKQ3jTnYUd+FR1oon8RU2iu/h
B/gZXmAC07J0FmAr2Ra2jz3HXuKWcFu573Hvcef5OoEJu4QPRY/il/Ge+IPxlxI1ifcTf6aYU4KL
PNMAc+Fm6KbZDsIU+DbNYj+lA+S1U/A8nJHTB2iDcfgzoQBoRCuWYQuluXg9LsYl+Cg+S+mEbMsf
GTmCqZiBZTIba2c9bBkbZm+yYS6Ly+dmcfO5A5Re4N7iLnAXeIFP49P5mXwzbOSX8Tso7eb38GP8
y0K1UCfMFW4ShoUHhY1cr/Cq8JZ4l7hZHBM/E/9LkaeYo7hNsZG8c4Zi9qdXrQQec8n6MvgG9GII
e2AbeWMXdsMIRdcifIBsHIS8RCd3FzeTlVA0nIBvUbTugLXwILcAdiXe4UbhbYqUpaRrGJ7mG8Au
bCfv3AMlFEXJBEF/vj/P5/XkunNcTke23ZZltZgzM9JNaUaDPkWrUauUClHgOYZQEHY3djmj3q4o
73U3NRVKvLubGrqvaOiKOqmp8eo+UWeX3M15dc8g9Vz8Vz2DyZ7Byz1R76yF2sICZ9jtjP4i5HbG
cP68DqI3hdwRZ3Rcpltk+iGZTiHa5aIHnGFzf8gZxS5nONo41D8S7gqRuqNBgkNdWCBtHEHQSIqj
MKN7bb+ZKqlHOGp1h8JRizskyzhPuHtRtHVeRziU5XJFqI2a2jpojMKCJZKdsEG7yL1oQywIPV0S
1b2gI8p1R6KsS9JlCEQz3aFo5poPzV+yl6jwxiuEUeZp7O4baSQINjQl2S6J695I3Ox2J6ll90U6
onjfpBGSjQOhpLl97rDU1DXgjKrcDe7+kYEuAhfaOsasQWvY3R2KRKG1Y8wStMhMYcFR8101Lpr9
0cLphdOlusZlvitZ/+7eZPtrJzVyv1O/oXp222UAUBrJ3Ux2Rp298iBuMrZKKvqqYKS3irrRL4I0
zSVkz4woo5jhPFHB09wdHW6/ZEZ/KGlc10BoTGWxSnPoaohQ/64R/TQahvrr3c6R80AudI9/enVL
92SL6NGfB4mUHH05Vkh+iR6SgZGGM7v7Jf8OhSd5tzl8RQPxEjSSzVFTtGx2a4cr6oxQQwwCBbNj
oGrtOIi4ORLDxH0xCNmP0puKu3khiQukUFsSovGJKSyghnwXUUUFzkZS3CjFinPEOdK8aMTZ6Oyn
YOI9ck2CvpFIMSHY3kE4wQ00YjCSdZnsi0SmkZ5iSQ8v6xmJkIaBSQ0DsgZSMEGdSgpm0zS9rR3z
OqLDoaxoMBQhL1D4nmztiJ4kx0Ui1Kv0sqVUr11inrS5jGwuzSeiPKmlnXSQisjISJJzu6InR0ay
RqQ1luRjCH/dEJxsiIGsgBCN4XCrLBp2u7JkzF1uF5kVkTCdQiF9KaJiUPH3Ea68EuGpZG2ljHDV
Pwjh6q+C8LSvhHDNtRGuJZtrJISv++chXHcVwvV/H+HglQhPJ2uDMsIN/yCEZ3wVhENfCeHwtRFu
JJvDEsIz/3kIN12FcPPfR3jWlQjPJmtnyQjP+Qch3PJVEJ77lRC+/toIt5LN10sIz/vnIdx2BcLy
LWMX3Q6K6W7A0c2hLugSxGI6mPCKYg7UAl/MccyqEhXFCBal6gFX77fMgcDcz2tbJmrn6v9Y26Kf
qIX62olaKZeWlBtcBh/lXfzm2MXfCse/mBHjWy4cSt5mDtDxa5zG0dAtYG4wV5HN8xouG+lAqMxW
a5RaptUyEJewGpVVxyk9YEnRxVBzyLX1QXnI5Igtn58zGKuLoT456DjRE6Ulaa50l2Ey4wG++OIW
LnDxTe7OC88xh3D8cLxhNK47QEPLN64zVDwszzeT3kOBZ+ULV1GA7jBQHANWXFKaVm5wnzlzRrKf
hNvpapVJ/dPg58FICGdzTEQVl4EW7m0U0tDGmTRZ2q9hB/cG/pJ7Q/NLrZpX8ylhdj/j57HtjPnV
eSlV6qqUmexrbIgpPItS1Iwzcsg0WiMnKtMzM608L8RwZzBF7eA04oQW2USKw0gtz6SBxTQ0aA7M
1UuQn7N8Xl1Nf/M5CYtwX+gjqM8kFIyZ1bPbVh9M0cZw9DBDptYQMcYYt15oKVozwa89tV5I1qUl
0LliOa7oXJ7mUqHL4DZMqaxAN6abMtIN7u1ox934JFqP8/HO5+PzhRPC8Qte/uwXM7jewle+ecHP
v11Y+espF38g+7Mr8Sb/R+FDKKazbzy40J/qc3u9lboK10xvj3eN7pu5qluVZl2mh0V0/brRHE6t
m5aTm6PmeJv5flNxccA2zcTx0wKqEqbWKQ25OY68khKD2ZPZrPTkWcscHkMzeIotpWWPuwYmI2D8
83EpBKgitxsN1dVSplAYr5ca9OMGAqJoorxzeWnJjNXBlrwigwOUzMu8hR7RY/VyBRCAwiK5EvKV
AbSnOQKQlW4OoMWMhXwAVD5NAD0aLCJa4aci22gjYQYVFCmBgF4fCKC+ViblMhC4++67oRMzMjPK
y6ZWVkzxeYvR6/NWTMktL+PT3US6c8R0U2aGQ+qTbuLdTp93KmK2YkrvF4MLxmbPeeL0v8/biMYL
v8MZx1JLv342umN+zSsvbZ23Mf6D/4z/YedOjrXg2bVzH3bWPb6qvMxTWFCx4MjP4u+dH6q//bs9
S8ucJcU5Nbec+vy1jRv+wGuk+J5C67mS4lWEfwmGHsLHkQXxBmQZiKuEj5DdwvcLD/CcJY95jBzH
g8coigIKjBM5YAKvVErxyLhHBcBHRYti80JzwELhZ26ZqK6mv2WuFHdmWvQUesZqXN9SFFhfZA5Q
AAYpcBE4nu6BTBTWK9fqT8lFaQl2Qufy5StUrJxiDfUUZLvem/j49YnfU3zZ+Q++mJFcmxy0JX4l
3/hS6S5fC78OVuWXoFpP68vmK2/SL1EN6BXVSqNWxWWVKXJVdr3WXhNgRf6aIzWspizfY9QrBKXN
l5Npi+FI0J1pdyh89iINs1doahW1tTaTwp+/J9dal+W3zUr1VVmuq/sJbqeL7lHcBleF2LmJU8ld
ZlxKFF1SaHXSzlM0XjSOVBsyq+Ugy6ucmp4DaPFgZaoLzNlZLshwmlzoyoGpzAVWe6YL011USPEz
GTrJkOnMlUPmOtRhKooKMR0rpQCieFGICncdlpdRvBhM1ImG0KE7x+f1SRXFVuXUNNStmHtzZJur
v2xZT2k7Hq5L1967ZlONS71H+NOTx4fuyPRosw35Bd7O/AzV1Jfu3Hr82e0jL88vaN79nXSbqEux
Fd+CS5UF5sIF7XPy23+2s6npkYntthyOu08rNriDTQM/fmDrU2l4TvJJU+IsbyWf2CAXPKgNrt6u
/J71aQcn6FiqYErXGVPTTUFt0KT0W3G25hnuNP6MO531jvJd1VuOd9wfZ37s1pw2nDayBUrBlZu6
I8OeWy0qFBkuu02htmdoPIrttqdtR2xv23hPRqrHJljUWoVB50u1+wSrL7dI4bNYvL43XLs7J18D
5+Q94I2JamM1uYU2gerizsubAL0VpH0g6ZxGcPMCJzAKb150eA16oz5Nb9LzotaTk5XrBSfYvZht
V2UqvKBJ13kxRee2uqhJoEJpVnshRU+FvPRl38n+yw/k343LO2F5ZyfQmiYvubJRcuXUch2S70R3
Dhj0UI7Jxa9Advitqkqj/uJnwkPbN91QYjqouL60bfX0thfin6D5t+jQ5M3af+ceAd38zFtvnLd0
1hNPPt9ZObPmO0WtNj2tF5FWVUPce0fjPYdG8FfJdXJdvIb7mHzigEIogiPBlkpTs7JZ1aGMqB7Q
7s3aY9/r2x04mqUJKrmMHL/ulDqHlgIv+u0WtdGuTi1SFBUJNq4oo6jQL1hLtDpfSp3XZ7MUl6x3
rWi4vBKqJaQnzp03fLkW6sdleJP4FrjzrNkaQ65H73Vne72QZ6XCoNG5IFWnTfHYc7zoy/J7IVVr
dMHkApjcN+U1AIReRbnBpBBdOV5f+eQmKkd5roQgyIsh3ZTcW5HdubC8YnftYPzM/k91R1J81937
ctDLVT6y9kfxC6h4FkNPfftEo2fLnc9dXxB/lW+oc89Yf7HsxaGzO3/Y5Kt9+KZft7X+iV5wKVgU
33Vy7OYdPz5+oHcdS56B1hGo44SnBaywMFh6RDwtMl40iT7TkLhSIZi0zGTW2wUFiGaN2qqwWkHr
V1ltWGT2W8CSRduNeMjV03DpbJQM0clzCmFGrymUYlJa9mnl6ZcWN719fcn1rkPicN2+OaP951oL
jthL7gr6Z1UVZh3Gp/niRxa2Pfa1JybmsSd7ahelZDRULF8y8TIZe+lL8URGRuTm1NrzYEh+9j0Z
fvfRy/WUeA2dXj6UvwJf+rJMteiP+wG0GF9+oUP9xmXJpZ9aOA27hJvgAKuGM+IobCe6i/IU/nZo
o9xE+TrKhBu9b1bBQ2jDj1kjp+fO8vfw/5EcA9RwK8XqUlASwnpK7QCKj5WjwMtSBOPkuCLJ4Ib2
yJz21kBT39KhvpVLeru//AKe6IO+a37xVktf5aGAzh+VUA0haIJZMA/oINccoNsZ5YqAdMKbboZh
3E027obHKXOwBDfAasoPUv4eZf4ytZfyUdwwxiuDz+JqsOKsoIZ33GCyOMxqjeM1cvPhRx3vmj84
hhZIgffRMpYCqulqesk+BovAgT+kHXIN2ZGHOw75lzq6SLQXBikPU+bkEnHvWHaZ4wQWgIdelQ70
QjaPzzh+V1ro+LA0xnDM8ZwvxlP102zigqmOk/ZHHf9mv8VxgvK+pGjUH5Oe2Wtf6tiSHcMdY46H
7TEkwXeS1R12evQZxzL/NseiUlk+Z1uM7RtzVJP8pqDGUVnlclTYzzmKfTElEl9on+PIL/2FI9cu
d3OSUk/Q4LDZtzimkSjbHvZNo3wMR3En5OPOMc8sx7NE0nQPNfurtsXwW4ea8ko9MVwTrGzK2+Zv
8nn8cxwef6PPR/RNLyjWKb6umK4oUwQUeQqvwqXIUpiURqVeqVNqlWqlUqmI4b+O1TvEY7gP6gmW
fYeUopKOxT+iRv4Y7pcb9x9R8kqmBKUplvjNYSmGTDHcd1gvUUQ8I8qUGMP9h5JN+4MOXqJ4WaBn
UsmS4clQyShgorgpJsJ9GUP15npjnaG6MfS3iq6rysDf/pnRHt1Gt6zoqD0SLZOIhD1yWRj4/34r
76CiryEgnakODQ0OLJY/47nDfZS7ohuG+s3R4R6n8+DA4OQ3Sm9XT2+/VHf3RQfdfaHogDvkPDi0
+BrixZJ4yB06CIvDN3QcXBzsC40NBYfkL5iHehpWdF411oOXx1rRcA1lDZKyFdJYPZ3XEHdK4h5p
rE5prE5prJ5gjzyWNM/wkvaG21dSdNLVmK6/ee3R5nnzO6LO7kgohrul+/Id8H+n6S6VCmVuZHN0
cmVhbQplbmRvYmoKNzYgMCBvYmoKNDcwMgplbmRvYmoKNzcgMCBvYmoKPDwgL1R5cGUgL0ZvbnRE
ZXNjcmlwdG9yIC9Bc2NlbnQgNzcwIC9DYXBIZWlnaHQgNzI3IC9EZXNjZW50IC0yMzAgL0ZsYWdz
CjMyIC9Gb250QkJveCBbIC0xOTUgLTQ0NCAxNDQ2IDEyMDcgXSAvRm9udE5hbWUgL1RTWUxTUCtI
ZWx2ZXRpY2EgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL01heFdpZHRoIDE1MDAgL1hIZWlnaHQg
NTMxIC9Gb250RmlsZTIgNzUgMCBSID4+CmVuZG9iago3OCAwIG9iagpbIDY2NyA3MjIgNzIyIDcy
MiAyNzggNzIyIDcyMiA3MjIgODMzIDcyMiA3MjIgNzIyIDcyMiA3MjIgNjY3IDcyMiA3MjIKNjY3
IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NTYgNzIyIDcyMiA3MjIg
NTU2IDcyMgo1NTYgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNTU2IF0KZW5kb2JqCjU1IDAgb2Jq
Cjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1RTWUxTUCtIZWx2
ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjc3IDAgUiAvV2lkdGhzIDc4IDAgUiAvRmlyc3RDaGFyIDY5
IC9MYXN0Q2hhciAxMTAgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago3OSAw
IG9iago8PCAvTGVuZ3RoIDgwIDAgUiAvTGVuZ3RoMSAyNjA4MCAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PgpzdHJlYW0KeNqUvAmcE+X9P/48c2Rmck7uSTI5JpNMks25Zza7WXb2XlhOAWGRFRBQDpFD
XERF0aog2noVRW1FWk/UsijgUi+q4EmtbdUqXj3QWmV7fIu0Cpn9PzPJAvbb3+v3+29g5pnJZPI8
7+f9OZ/PBEAAgBFsBDiQF65YsOqFNz6OojOHAYC2hYNrQ/e1thZQ+/cAEPyFqy5agd367xUAkKfQ
sXTRxesvXFP3rzgA+ggA095esnjBoj8/cfIbAM47ju7RsASdMAb0LwIwN4WOI0tWrL28MN2yBh1P
Rfesu3jlwgXv6/+K3hu4Hr3/oxULLl9Fb6Y+AOD8EDoOXbJgxeIZd92Pvvt8Wf38qpWXrqU+p0fQ
8SJ0/NyqNYtXNbw+6QkA5qHrdeh7AATqeNQRAagD/9c/CDBtjxNoTDqKZvQGIzCZLazVBuzA4XS5
OY/Xx/sDwRAQwmIkKsXiiaqkOpp0Jou2ueqa2rr6hnxjoam52DKuVW5r7+js6u7pHQ/+n/8m/L9f
2gfARPD/649cCzCyD/jRfw6/Gw0KjP4J/UcYjn6ptKP30XvK86Pv4QF08R71P6a0FoEEeLABbEOs
2AA+AfXADeLgT3AcOt4D3gafol7MAQdRzx+HPWALmAwKYAVsARH4G9AAusD94AX0ifVgJbq2G9wO
BPSpn4++hM41gMfBMDgBGOAHLWA2usst4J7Rg+AB8AX4enTH6JegFtyArnh39I8gi1h5C5ogL4ii
ey4Dq2AaWzu6CYxD37cN/Bx8Al2j44AT1IEi6AQXgSVgBbgEXI/eex68C34HeXWWQA59TzeYBW4G
d4K7wRB4BQbhlfDHBDO6ZHQZOBf1YBn63B1oNG+DP4N/QCt8Eb46yo/uGR1F3y2CRtCuvf8j8GOw
A/xEHQl4Fb2OghE4Hc7CRbxu1DRaM3oSXW9BqMlokuaiT6wAV6GRbAOHwJvo9Sn61jhsgDPhKrgR
boGvYu24naDIyaPXoV7SCO8W9JqC+n8p6ultYCvC8FHwJHq9DH6LkGegiLVhG7HjuBWXiWnk4Og1
o7tGXxj9FZoREpgR/n3oNRGsBZeDzeAm1N87wD7wEngfzdXfQQlSkIVu1Ic98GP4FQYwK5ZAd3sD
X4lvwXcRgPgR8TE5jtykPKwcHb1odOvom6P/RqPHAIWwj4M8ejWi72gF08B00A8WIayXa/y4B+wC
u8F+hN274Aj4GJSAAgNonHnYDufAK+BP4UF4GP4LwzAWC6LvTGCbsO3odQA7jL2Le3E/Hser8fPx
u/Dt+KPEneQicjX5Q3K37itqs7JQWaQMKlcpz432jd49+sToAdQbAfVGndNeMB6NdhqYgWbwQnCF
hvUWlUuoP0+Dvei1D/XqWfAc0mRvgz+A44hzpxAOjIYDh5DIwQIswnGonx2wE46HfXAKnIHmZxac
DRfAZXADvBpeD3+EXj+GO9A49qDXfvgsfBO+DX+HXkfhMfT6F0ZiFMZhIiZhMtaHXrPQawG2EFuC
LcVWYN9Hr4exXdgebBgH+Di8G1+AXkP4Afxd/Hf4p/g3hJdYS1xJ/II4TBwhjhL/Q5wgWTJHziTP
1XG6gm5Q96DuaWo59SR1BDyFMP4ZGtPZfwvBeuwu7FtwNdaD5Ow1ALA3sF40Exvg0/BBhNRDiLd1
6PUResnoVY1eevS6DmFYJcekaEQMC6FgwM/7vB7O7XI67DYrazGbjAY9Q1M6ksAxCFJdYvf80JA0
f4iQxN7etHosLkAnFpx1Yv5QCJ3q/u41Q6H52mWh714poysv/I8r5fKV8ukrIRsqgmI6FeoSQ0O/
7BRDw3DOtNmo/f1OsT80NKK1J2nt27S2CbUFAX0g1MUt6QwNwfmhrqHuwSVbuuZ3otvtV42IPp1C
xEBIGNQbD4GOBRuWcGinXtE15BU7u4Y8Yqf2Hh7tWrBoaOq02V2dPkHoT6eGYMdC8YIhILYPWZKV
j6ufC6FLz5mNvjudWqr2H9xsXCQuunlYBhfMV1sL5s4ewhf0D2Hz1e+wJofcYueQ+4rPuDOHY62u
W856cwiLdi9YvKUbQXNzb/lwvnq04BZ01Dc9hG6L3dA/ewje0F/uhNb38igWi13qmfnLQkOM2C4u
2bJsPsIcnDP7Ka/s7RIXdPYPgamzn/LIHu0gndrPXd0sIFD2p9vSbeq+WeCuLu///L3y+d8cMGjX
Hfw92vedcxoXqH6TOB51cyi0UPsSEfW1Ud0sbgRbFjaiy9BfP0SjXDrEdMzfwjahTw2RUVYMbfka
oIkSR45998yCyhldlP0aqE11Ok8zAr1faQ+DWKpvGDBTZ++G8Af9w3D0hmHQ6d+PLAw+73z0dlyl
w9JO9Gl0kEihE1UCalWlQt2o193qvIW2hLaMX7Ql1B1agiaciGp79MbiLf1ZNJzps5ei7YzZwpDc
7zvdXNzf34Tuk1TvQ2j32dKP7rCscodl2h3QDUroolSqD0EkTZ09bfbQxk7fkNzZjyBB/DkwdfbQ
AYRifz+6Kn26p2i/YSlX6XMG9TldhRrZ8l2mo3ugW/Rv2VI+EoWhA1u2+LaoclA+HobgP0/IlRPD
QLsBosow3DhVe2ujKPjUE6IgCqhb/Z3oq3KIXmPTi4QGQ3oXkHcjXwFHOrhjDwbHk7pheK7MA4Ia
jwM9SYzHcczL6KjxEHho5iuh+xwumZx8vDipVJzMnihOYktF0FosFdnjaFOdq7UK1hj6L5CDwye/
Jfu+3TuMf3gqqn3Xc7gX20QuQVbNDy6U8xbisMsQlP2rLKsEl8vix+0ePujpZYN2s4yvIlYJBgOB
42YaC5p7ySDtCQTvFS5eqX37pKOlo1abu9CS9R47xnnZT757nAUbspzWHaCjkCHPwPq6htoal9N+
pulA78C5JJZL1xFEOpwRD9VQeFLKCZguS/yrllUuhHfzNQ4pW59VXPAHLW66IZPPMI56ZanqXp6v
3ImtRGOxgi6ZN5oI3EQb7QRhNOFWk93udnuJn9G9Vo/NPgwNTwvfK4M2qXR8ctfizs9Ba6utUIBW
WwHtwOvs69U5m70h79ZROivrtrkpKYZZz39748/sO7rWZ6b93nvlrSP4+ZDacYGwcf1vlR3KqceU
9+8Ump+Afri87O42oP70oP44wAQ5xGDQwlI69A83WCiLjrXq7C7UJ0ev4WcWj9Ol9WnSueU+HS99
t0/uAmC1LoEBgFGoS1SsId9gZWNYLO9y26xYz+S+KdfParbf23N107R3vPdv/jVcqJwYvHpFr1+4
7Ir34UIY3AfhncLsp5S/Kk+gvv1O+QieQNbajvomvUZAHKNxDNeZMJxm76IMTtSz7TqoS9oPmjwO
50Hh8krPSleNrOEqnZs0UqitHetddQ4OEKhf49BkSiIVlipzCk/cMcM+f7xN31HV3dTeumjqz6R4
w9VVZprK18UnLpyN+jIV/gDrwcyI7yFZD1pw6CWBhyCH4S40S9r3HmU/B9lJI9U5u+AUpsJ/KQxm
3qhh/NHoF/BF5PMZgCTbySqDwYR6TldhHqPpZeHyH1Q6fbrD1TlCOk02EQbaO7LZ9rYcp+7as9kO
7Z7E6CdYFs0bDsbJHMDxKTYMgxhOoGgHxwyV3v0cVgEBPrr7x+grPGoHOSRyrUWIJmzTpExyA3sI
IVILRfjmIqX5QnLJt4OavNlGR/Dd5HwkbwFwhxx+An5l/MyBHwLvgc8AXg3qyYIJn0jrHgiQ5gdc
JmyzbRijnw7pN3uHMWp3KJg9fHyEPTECWkda0Vg61suNwG+UuKhDoqO8xEYJyeTW1wPgxOoh5Uct
0oJaBo+5HkA72jA+XT3ErWiTRH/apvJ3LVw9AAYiNmtdDBPDuM7pcLtqbaqTQmFCOCZZ2XxDLbbh
EmHczp2tQlge+tM1i8ddpvz+0DWbz7tyNIpcu+p/3g7Nypc//J8/bVbI5n+8XHp1SNn79IuwF2I/
L6m4olgIj5LnAxdYKXsGHTc6MMnR4MCMpQvo34fxby6gfi86fm8ahpc8Zb/AMQyvlq0mI44RtJOk
KSOH5hXDh2Fur9Fo8ri55+DlCP+H4ACo6D6k9CrTXGxFlJz09cgp+HUyiWQGDczltDpcbqdQj+hp
RfwM66j6aC12ATxnVenw+glc3Ds9AlcayX6SOTlxUhXBB3QNc/D7czV+ln9W7XsL6vub5CLgA8Py
xKgNXgwugUvt+CLsLssJywkHQVp0Dqcl6iCStAPpb8h59AZo0OM48OKcx+rhDHpI6hy65WbS6XjQ
KwPBZ8Q3W5/zPIvRSPUiqd7t57OHj7InjqPZ9bYc5rxIWbaOqNJVVkpqS1UCFMl6D2lzzxMsHaVM
aJYZvdFAWvB6yBjR1BIs2gB1etkiWxyb2tV5WhPNMKVJqSYCGBRqkI7DhRZ4CdQ9sPKmmdlksuZv
Nz326z8qN8I350+u9q489Qc3vAoueuyH9y3Kr2E+f/rdex9U3lauzPQblb+U9Vz/6D/wQXIZiiG3
ysXxnvMojIq4IgmqQPVRy6hl9HrqSvoxzysRg1vgODfAUzDMmjg3ZjdiXyfksEk4wECGydqRXr5U
tvjI7OaEiV0eIJc/IEHpeQwgN9oEG0AKY3ZX55AEIJAGPnunLAQImuxAi/fjDQgwtjSGVkHFystp
SgkMNLhqaxrq62LatFcU1NkooKZLJToQylrrvb2tt2zOD3xs4ljsgeHbBy6ZkakPxo/ces8jXbFz
5jetUN5Vjl25UIj+bM3zK5dPuwli3qa7rlyxZlpqLrVt36OXLJiWKSTyS3e8oHwyvsqbK2PUNvol
fg15DUiBt+TYjT5YTzucEGAJN+kIO5wGI2Nxe1mL5VKbz+f1oRZBIvcJ1siBKPOgz4d5Pd4HZadg
ZQnsRNRELg/ve8A55MScKnsyIIHYk0lr7Bk4ruFS9B70looICWR0j7EjmpLeZM4kSaSXgLWgQmSt
RbrKqiGFcOIQnyQ+gtMhISgEBL+AdLlE8yTSFhG00QlMPeR9hIgh5YJopamOqmuvhRVw2SiCVEKA
5u0aoygzFAUVVXcAImBFpEBUZH+zv+bSJ5Rj91zvMtAYjh2BT4ZEnp1MRJzKhpkPTtwwo3eCcugf
FxQXJdPPXPvmDyG+phVnaAMJP3EFzPsZchfvqTqnZ/fCj5X37cGpAdVdQjq1G2H7Ank5cKP4+TZZ
PM+C0GX07ijrc0xZ6YO+bh8m6wWGDD+AmaKbgRu6kVLdE2ODm0lVq8YkxKnShoMcQk8Dz9vySy9n
KwxmuYERa5lPmrxJoYjTCwiP5HVG66GAB+uBCFGLc/nqYYgI14MICKv4VDTrtddeq9prMQysbLRB
cJshgoVChltlnRTTSOh02FT88Be+em5I+RRy38JGcsPenvEbuXHpqdO2v/9MVfej99UGbr5r3cWQ
VY7ACdAGF5TeEdxTeno/WSHZQh8dbrzoibkNV/9Uee3NzWWuxZGNUf1HI1gj81fqN9E/pfCl1Fp6
C3U9Q9AMbQQMzaBgE2nTtOxWjRsKPHEGmgEkyAeBER0ZgcosM2CQzJlNKrM0vap6mGV1hOikGTlQ
cZoKZe8EDkAnsnlCWdDy+N3K5OvhVmXigpltYlvQQ/YJ375MvCpfyD7Q166mAsEKNHebyYXIfnOg
FiblnVuoe/1bA1uFu5N3pe/JbK19KPBY8uH0Q7X/TJvItCuNJYkWoknXVN1U06HrcXfHuqp7aubg
A8TFxFLySuJS46DpMtel7su4tdFbiJvJG9x3R/fie4l95DPCB/ETRDBORLh6HNcT+pjH5IkUiSap
GJtDnuc5z3te7TJiGbnMs8y7rJbtpGsljiQsTm1nsD0QJA0PpEyW5eFnsOUg8UACSyASyYZ653J+
H738xSzMqlyqr0NcGhhRjbS6Lasod9mF0zhUU5XxC6yD0QOoT9MqWZB9tgec9cAasiD9nTEgS12F
Ng6/rR6ygk3T5GcIpYocMmhIo0eQSpNiZiReyE7nGzSlhujkchOx0y4O0myq/OlEVbHlG/LY4OCG
l86d/P0VyyPjLls39/LvX6r8MTfhw107XljQuGHnnR/s++lfptV/L7xx/opNNzU8MfWmn+Dj0pNW
zLth7fTzd/ToW+evvX74Z5deNlDfdfWz19x2cO8Pr1nQOrssgy2jb+O70DyaQRLsl6d+zn3u+Zr7
2kN08+f61/nW8Zt8m/h72bt8W/md7M8TbySOsEcS5gzt4ThPPIRDnDR4opzaoKNT5pmhebyZox9I
kpyJ3Ays0Kp6QWnD5riKcTpV9oJUYW0dUeV0gBtB+CIWajir/rvKRoR2WKrSsSYJwcmomFIWpMqM
MeQH6RM0UmosrflBUINWJS9oyKvmASsjWetF2J1xt9FbefVAA9NWi3Xcrid0t2y6YP3qHx74+5oV
17y84mH9kq6r+pZdw4oTFtUld746sh9rmejVXxt/GxJP7b7j37ik7Hh/m/LKlT/oijnjnK+6Z/E3
M7yNTuM/HnkXOjQcHxr9G7wJfxLJgxvUyzxWRVPWKrfBo0YKVWZDFUmaPZznZeHUyjG3Z4Q9496q
TiEod1AjAHa2s3t9Vyo3Ts6kuu5vk7PZ7vY8bmrtTGXaWrOnhtqz6Y62TKpb0x8to38jegge6MBi
uYHU6aptOE7oAFBbSFnoSFyHkShkoDGA64hqcotuC6iGBuClMQ9Ffyl0z6r47B7QyqH46nhJNTSw
PDU00hsEUhxoz2mN6lzUCeuR2iB6Tp4g9CVs0zZ4Mg9PblO+h/piQ31ZofUFRac6UgfIahtB4Dqg
I0G1DUJMh3pCANQXnMR0sBqgzpDVhAHz0uC/d2ZE60xZhxGoMzTqA6F2htY6Y1e7Ug9txHknH8Kn
4NdvU8i8Qm6DG8s834R06zTyIjQ/aXCvnJdojwWzh8VALBBOgxiF2btR8GHgXHafbOPsAo2MlzZp
Vb5mszcbeVSoq/JkssPQ/LRweSUAHRlBQfskzZNRNyhe5l7zvuZVlSpoLXnfYls1N6cwpkK8yRQf
MpqCKcGPnH9fFIaSAT/kTYFo2elT1UTkLBLYyopArCtz+LSiGNMLyK0/pz2dlduTmY66N+95xB9x
sWybkL5kcNrKc6rFuPzUU2m5NZNpldOk6Yl7rvvFb56Pbqqt/WHf3a3LH50Vcw3EhZqujot+ruEz
PPon3VYUOxlAH3hBvqwgdjI/DO3I7ajeUbOj9k3p9SzDmV35qCuaL+jr8909nb1b9Dfm79UbAlUY
TYdTu2JwSgy2xmCsPoyFvRYBCj1CrLlDbg7bQUc41GfoTTWSVUk8UB0IVBuqU4aeSCrS2NoYVu36
pNY6y6SJ2YPvjbCfrNZAyw7+ksse1mDlrGUlobrXf+FaW/7i5dQrVPVxcOTYhuzAAGqUytZeUwbI
s7FpaGFOrBwACSHVT8RUdwZpXg09gCB252tVxaCFTOpHImJIyxq4hJq8mkJAbtNIR+O625vqFg9d
+vs//vsEMpOW519RfrK8NgzdN05cfR+kftSzyCI8mA97q8xczYK3lHt+p/zzvS9eGoaueaufvEq6
SznxI7hnIry2v66oHL6p9NcXfgEdsPDxR3c/8M1rylB7qq7lwnuvfQz6xtcv3rl0zh1Rh6cKGg58
9e3+15RPlX8+9CO+6vzC/HM0mxsAgHwI6WoMhFAIVZR34hac9eAewmaxsb6gL5TEk0RCV8ALREFX
DBZDM/Uz3bfgtxCb6RuZ75m+Z/6e5XvsLcFbQvfi9xJ3mu4032m5k703eG8o0mnqNGMUTeuA2+WC
GMeh/x4PJHz4IzrWZzH5zHG9gL7AEnJ5MA4HyCW6HNJMiNbpUjZ0IaPXJ2zokzoP7tIztECaocel
1xFcCNIAS7m5YThTNjKywNB4yGLGabGNwfTADA8BCHvRcHCMAeHsca+nVOJUj6WIfJaiV40NkTdc
qIQHmh4a84bRntMaSU3GCgWNFFkwArNqMhSqLbWxiSU3HCxuYosUW0Q7cxHFFsgOGyBEMWUeRfoB
WIkv66QsFFS7jLxfJ8TvGPlSWThlynz4eBwqtS29pX/NqXPYZpa+mBqs8vbCGGbG6kqHS/8TZS78
Iz5yct3avD4apd1py8SqQ6/3e+scRl0UTRaaNxEA4nnNr4uCGvC2PPVG3w0BrBHvxc/zTQvsg6/A
9+D7yc/gF0l9hmYFky+ajlgFnzMt+mMJhjXS/mrSGkvX9FUv+5SEvyIhSUad6QwyE8ZMJBKlE8Ow
VrZ5ZmMz5NDG0IshPFSXYxJWdhjDd9fVIqOrphTfKfs1RRYFGeXoa3XpqLVQKKOnuYJq0I30VKgq
JYhuDsCkFJZS7sRMCERsJqzi0jMhFIwzwVlejSpvmkMjVsEYCtVryXKgHqsXaojTfgyyvQLIj4Vy
TmseU97594Gsx1tcUXrpqvHjr8LGnYDC4sKa77/2yWWPlxZhL3Zed9f0x+TAyxOuePKJq6GC1Qej
VOul+K2r23TS/b+4vS/Jh7ff+vc5WexvweJ9z8iiq1qpwVU9Vjv6Ccki2EXk0z8hez/gP3f/icP7
uaUcFqddbtKnu1qmfQJFDcM2OYwOsB2Si7K43DaEpYjbMj4mEglSC7a7X3T/yo2jiEP3tGSZERzG
yN1SVHNglIGjCD4tWkNhhgYd8LZ84eWOI8Z5W0Y4LwK64sjwfNhk9UcFycpb8sAURhs2YMsDc8iY
h6dxHNNaDflau6gFGCjyQAoqX85jiqGKFgvji780++v0SXs20X71u79T/gaDH22/cdJcqXPxE68r
+156+vlXYStFLmwPhZW6m2bcrzyhvKf8Vdk/MTlLOrftkt++DCMw+ea7lVz1BsRJM8LpHrnmVR98
lB6mh717fd/QZANtEyy+SDxiF3zuuGizY/oMhwJ/LCOKEVo340Ue8giYvZLJnLDbVJpp0Kg0UwbG
SMaq4FQoFfeEcSbgD/pDfsFP6IioN0pLeFiXh4wHbUg/lgeUT38aEjVE1ajlUkGwsjFJUHlzhlwh
N2Etu3iiAB+qnvT3+/568FHlq65q5apVne1rsDh0/wLO3XD11HN//Fnp1YtD8+6AC2Dz9s2B2pN/
W28srMVvXSXT0tyHlFn3KMfmFYNNKnfcSE5fRZjEQQK8IS9fHBuM3RDDza8ZfBY91F9l9m/z+iwe
6En7cQH44vEIIfjouOjY5vYBDnJph99hxj3BCMNFY3o8IoUJu5m2SLvCmbglQzvsKX8gEE/QiIiJ
BO7h1jJ9+rVAmiph0jCm35u0BRMEroKZrKqAeWLg+PHjRY1srepOPTfCjoxU8koq9zQBLqdyvx6A
I8eSyfK+cqgmUvKnUbOLGRTeq0iqwX6tVTtUpVY9wgXoXt3RvoaQqTrvkj3Kl2knbP5eryuXc/de
pxyadODtV6YUBk4+ic2NagCu6KAl5cjmqf64kp+8TpHWTVLIFtd5u5SHEYSaP6riuQAdRMBj8pz/
CuMEoLLsP2EMCj4xLpbBxIOBCILxNH4ijUVEFH58y/Tl9FP1b+txvQqedBq800w8MTAJgadlFSvI
FawV0BBcyf8DXP93sJC1cK9vRjh1UAXn2seVLxJuGD+N0/tda0svRU2tN+DrygB9v49PnAZIXt3K
lNdvqkf/RO5AeioLcuBF2fc5BuO0eIUv8EjYI/j8cfFsRUXJ1WVFlY2KHtyGUIgZM7ksUlYxhlog
erhEJJdLRraLvxKxrDhFfFHExWGMeLrGMiOp6q2a6krgNaCSCNlU9mhZe6nAqHmkFu8xVWlB1BhR
1VhFavl4xmRNRNOSNa4qr4yqvKpU5ZX6rvL6b6qr4QyQTtXFsjqI02pMxFd8bk1FTWk229qx/qVD
yruw6sPoovT4SMdqTD/RU6Vs/6nyzlt/2vsqHC8gZRYOKdO2jt+ovKs8pnymvGS2cGIY9gw2UZJE
OkKLlBWRy3f9AnbBwOE/aLwbW4dLIs3W3+3rjmEmwcfEVWSd8bA4wReMh1XqJceoxwo+R1z0Cr5A
XJQEXxXail6ciCY9rIkgaIs5FYlGA04HQ2PJqmCAZsWEx4sQ3ps2SRXaacGtyjLVYxlzYDSZnYQ8
GLcmomMpezW1fRY8yOWwCme1zyS8K3QTLi8iYAqrO7EVSLUVVnd0rC69ur65dGcn2pe5dkk7LUl0
+yXKanjrWPvU6lWtyCUxyjfAHyhzVsmIeZrex65B2NiBA8yW4yow6bCqzuxpDYy0aBZ8NrQ1EThh
V0dst9EOFxqszJiRRCKNT+D7MRw4s+pwkTyxn2e1FJPKpEnl4f3H4LRBQGHDhAkbsPPVbeknMBtl
CuvK9lzSta0+tXpdgYlqigMC5+gX2AnU9oIrZeRFbOFQUGgTfOZ0mBF8prSIE7SXsZnmY6uwT7G/
YQTW7TabMDLjZhga2aNnMQLwwIsxu3mfllvVZkS1SIMHB7iKxR6zTKzDhejpouepboqTnAeSkC1q
rNaSzGqO7+yRlLMIzhaxqz0aD05Yi01c17Nw4R3zlz+Zfbx7Fr59jYzGQ/UsK7FvLVw0u+GMHnxd
G89quWWx5zLPjZ6tnoc8ez26M/B7x7jocbtwM+5yECaa2+XIeNEMoJCYC3FTOZxTVR2vTYHKOXV4
FVWnGohJqmVA9kAdoEa27yr/sakIwNqQpu41bY91rJ7kjrlru6H1wJy6RSefOqPcJd24C0/FwzES
x+bsV358eiy6L9BYokhrLf1cgBTDGHS8x+DmE4aCoZs/l7+If4Mx6Bm9wZCy+Xy8nmEStkDAH/Dp
cUCZKJ/RgIYERDfu8Ll4fyRKOmmZF/zOuDFudcW9kXiQjkfjOLqBnye9QZ83wVpVWYsFgqnyuLXE
rzZujYFIgR07xh5DlvHYMRSEv+blQKu7WHJrEli+gKTYJIFCAJJNsnSxvLpwBhkG/qfgQRFatTBA
cF/T230V3AqPwENw25r29jXIYW0pHedLperQSiUYNfX/BJdXduikk/8iGInuWFGROn3Xdfi2k2uI
80/96tFawRjV/IvRL8hHEXYoegPb5PYPODjbs8TzseFL85fOz3idQQ2iPB7OY+BoD0EDO4v0v02P
BYAvSHOMIOAuzq33GqxxoyHldtvimlQaRU8w7k0RTDwU19ARwwidY8eKpWMIoGPa+tqxMYdBdSRO
qbiUikVtLUGLrymWTLJEsRw9a7DEMiiOF6AVOexjzDmNCESQ8OnWVjgPd9YIq+EfLpssnhrU0MDe
0vDYJNR7MOmUhD35WK2glyTjnB0n3yAWnvqjhoQq5DhoQfbvSi3f4EPC+pBc94rtDccbXvw92xHH
ES/+pvkQe8j1Jkd8aH6Xfdf1IUd00HSGt+AYknKe95Ez5tuhHfmgz9xteMSAGWb4VEMX8KuGbuDE
wMhpB72cvAVeT9QpmSRrFHKGPMBdJPI8zaiFhp6HSFfkAeFAG72RzkOdjc5/d5n1WjiACDMAbLU1
qnUTw5gVKycVrCylE1S7BmFU2b8XQuXUU8OjX7z1PArync//8p0XlH8qv3/hF9h2eIHyJkxrBXRV
ypvKc7D3lb37DinDytOHhl5+FTZiL4OxGhJipuaXx8AhufcV7xs8ts/zuh+zyfpAkrZNsPhiY355
WPBJadEWDsTsOCVkAhl9H9VDSW5cc9ZjEm2ewfpyvqk+3KcqjoQuXPHWE/HTimNE092s6lIOZpHp
H7GWPctkRT8GPH6DCWDGKJQMfvNMiHnQxsTrZwLgxWfCs1ZMxs9YLzNMkJoHaCokQG0JU5UzUAn6
kN5Bvnw9POPDowCRQOpULAsePviTWTe0+vNh9vvT7jz1+GVNbZdgPCSgQ3nrc+EiT8+VpZeJO7sl
T7L0JYnFx792arKh5xp83fJORnrjoV8/hyu3rC0ympy1KHeS5VxWHHwqZ6Pcw4Y3zC+xL7neiPwy
+qH5HfYd14eRD6NGRLjYB46PY8Q0Wvb5BN5NZxDBfg7DIAz9MjqU3aKAuUWMNPALyBlB+3b7i/Zf
2UftpMq8p6sMM+Iq66oSlbBw5KiKnJoI3HD4MOcFrSdGWkfYj1BI6OU0MIvhGHBJsWgsEsN1FT5G
/gsfY2N8dLnPMBKF3eqi8BgpKxHS/4GTpLqE5xTDESTJWSipBP1f/GRf+PUNtyn/vmpo4aMzHlZG
ly59Wu/dOfDkf2Pq04eUvcq3e1+ufbqvyhFtyDccII1TFj8Ls6ASN5HNiLMGUAX+Ll/e633Ph8X4
/eKh8Dvho+F/88fDFBF2hp1iFR8Nkzy90/9zP2aZYESOVqTselmikSqWMojhcMLm9yOrEOb5iAEa
MuLUyPzIxshQhIhEjHa7j8o4sJAx7kuEad4fFnlIClF8hmeFjPwLleMpfTTBWlSOp5JngqiRcj0T
pxVXFVtHyvmPg+ra4ViGsbAJ2YYNbBFU+M8lk2BAmzSbiyN07igp6VyI8ARHIdaXVx605fmz8xpn
uF3j1qqiysklSJUZjq2d99M7Jl87K6ZsHGxqW4nldw/+/tXH4cOxyS3KPoVbg0KHV7FDUsf+p9pE
T0ahSksM3RvxdRd3MFJ65tF7HvSWvsmldFFskFRWrGnRa1yfOfoZPoK43gDyMCtLVnG9/krDFsMW
458jn0WpPrpfPzOKGfRU9Cb9TaZN0Q/170SpBjWkMNVfLfdXL63GqnekMj71TNB7tXyu60IX5toh
2eNRk54ggpm8HScyGUau89UPw6WyBfgaTKw+Go77qLzH50Xn9vK+gG82peagLHkfm0v+LTmaxJOF
htnhYXjVM4DNsRhbaMwefmdgw8hRjn1nAOE7acMId5zzjhwfyZYrt6wFFh14K1kVtQqg5diAGouc
bqxeo01HXShN2iLm8EzAJNBUkGm0CdnQISLRTBCJmk10lX4mTMQZvS5FzASCNTizLDtIespKaSxu
sbvcYxUGmoyU8+6VWAZFe2EtMxyEWpGB6vipdQgiDq+v675i7wW39mbv3jUlO+utnd2HzJKfrkpX
13x88YwNudziPY91df7z+Xm/skQ8RLoFfgZ/tOWcW69auWhC9vwVNbULLrvvra6IoEw89KOFs6c0
FsatXDJr9uU73u9NeeAe/HDZz+KRHRhGMuUGW+VxutdwH7YL7sKQHdmOYfPgPAwLwiCGWScgfzhM
Cz5jWrS/5vJhbrsV6CBNW006ewYCzGSkPUgunsL64DCkZTNFJ2xB6zzrdusuK2FFp54Cfe79GAO4
7PHjxweQeBw/fnrFuOIqq/mtj4pasIzs4MAAq8bJdi0+TsKznCYNnThxg6E6svKpNcjLf/w6ec3O
K4M1ZJ/y4IMLT36huvhRffsNBLjgIZW7PPIBfqr5khK4XZ470zvDN+DvD2wzbAs85HvW/22QiVJR
QwPVYOiiugznepf6lvqXBh7zPxYwIl8ZxMPuC1HYEjZfqAYsguCLxkXBbSYIKWq3AYzJ8IwkhTiz
KcW5VQcyTpCJkKDqhnjsOw5kxVdAf+UYbWxBXPMJ3VoK6j+CANXkV05hCwa7U+d8dvLc3NRV8Mi6
8W2XK0PKnsvbutZiyOeX6NbVpdU75jz46PkHMecjMw2SZOrfUfrqnXUfvr/2BWzjqlZGKsesyDe8
A2ERBCW5Q13LxtyedShQeDXwavC9wHvBb+3fOhjGzjg8do8jbo87dDTDUMjJZsB4wFD2NGfrsTEG
hxUGfMGrfPLw6I1yNeP1hDiPJ2VDTrrP602gPeXzeigiaODsjI8zMBTysFWwvB7GUlahT9+nOlZw
/9P3MZAZhpNlU2hqcGMQk4MQIM6pXAlljyMaeD2lgdIA9/lAOfornlXCoxbSmTewh0h1eU5tJL0c
+zVAurcIy44GZL+utNSU/Om0PMJdyxYgUjGqMq34n+pKLnLJVacUa5/EV4s5KEPR7qgNdMGftgWz
GaU5qFDypAkIcMiw1Z45y0p5nKjtdjU7jZgkMt7Y4MmNxIW3dpMiwpoZ/YJai7BuhPvlu3MMZAEL
HZ4QCMG4Po/0aKO+saa//iLPUt86z+W+rWAr3G7Zzj4EHoIPm3ZZnmQfjj4s7QF74LOWZ9lnos9I
r0RfkcLaLFqBjaA8lBejcjCXq07rk6l0ukqvZ7LoKJMx1NbV19dAHxikbT7r8x7JF32kyuJj4wbR
Fxn05X2N8Xo5FfWmQM3w6LqnmZrqENrLM7yZdChXHahWJ1JflU6nbF6vz5DJJNDeU19To04sXV9T
TRONuUzaY9DrGF9V1Fufq0KzrT6joK9pjEaQl4DVVGfSTJPb7Y0Ow+49IeCF3mdhL9gIGPiSrA+B
xo2NWKOn0DQM//i0sGquttCJZnpSycuV1BkfKyGt5De+M+vW/zLx322ohSfIrpYX/AsaJ8qLNP9t
QyFSFCkUrpmLdFE72FQO3VYPnM0TaEccOZ1m0ojTUDbJY8zBKVyM4VA0QAydg6Mt3ozBAONHFvga
Qm1YZJI/Q7MwDoGLJhsCRXhX3l/nPTLzyuD048qh4J1DK2bOQbTCGGvaIQVOKVj7vzrdZihJUG+t
t/mqSgB7pjnjZQsuEyZJtNXfU9r+lXLLCDZ46sdwJ/wUxjeRUlmn71GexxYi3llAlxyhXojADWH6
o4h5g0jRZghYs82KJoaiH7JYgIe1fiBcvB+6/3eVpJoJVhMtWlGtVoqkKqlm6BT2wF37ik6jydW2
S5lG9lVLDvHb7RlXrA7A0QNI4V6u1ca2yR4cw6bYIESnSEJdNYF66CVxD0E+Bw8CAS6GEqhUx56o
VMdazy6PtSNZHI9lN5V+RS75dhu6KRpbp/I8PK7FLR1y+PTYTOrYoImFNhYNzWwGD9GUx8J+IAzD
bbtXnlX8fqZqWhsZFOrHtG4SokD0uDL1mWaXIVYcgkPK8zVRh0heUF2oQ6PpG/0HfhO+B/meMmiD
RvnCL6WTEkbFunWYUbxXf2/hMf1jhkdNzzFvMG9m38x9xHyUO1J9jBnJWWbRqeoqNx90BEGtxQIt
42syDYXqlEUPdA7aURulMuMaDPS4FkMb1VaIsYZsW5VcvT6RrdpVhVUNY0DWd3AxX2e4neiUhzG4
u6NdDQOOl9RivuLnCLBS8agab4+Uyx21JWyt5OVwJQldrgpoHtcqxo1uSGFRk6STbBI0ExKgxhEB
4Iy4AygEsEtsAMbiuBFIaM7MFrKVDgBrzBE47dZAzbUZC1bLy3KrB+Dppe2G+ki+IVp2U6lyCQF1
utDA7apYuYa8s1wlE6sUy0Cs79K+24qxXPt6Bdw+F9od4eW1mYw+6vSnc08+8lJXlDYl3IFoKNrY
1NmCT2w475xzr4YbsCop07/6vCQ/obB8QfGimRfGO7y+rLFAN7pMzZHue67uul5Z2eSKmX11MY80
u6U91LB+ABspx7/U6Aj+PLkWcMgr+L5c9bUR6ozwXhMUaXjEORXw8DZRF6VEwadzGnAgjDNQvoVW
Q6DTPIxhsh6FVrqs44ATOofhaDlPhHyao2OV163llEd5yU6rM9amgONDRjZkDEiQZ9EmaBIk6Lf4
JDBWlqHBaUdOTi3CqlIHqBZHaj6ACMpOZDkEoNbsozBv3dzL73xb+Z+PVr4XaoLMlrpbNl39/Z7N
xL/DXlmnK23PJfv+/co7ym9mpwihqfrkgvRvtm4tzepQsDIGWYRBH74LhIEIHpPH3+x+kD5ofc/6
HvdH6+cBqt6AfCHDMmaZfqlzqesKZr3+CucVLkOcdnOUnnVzmJuzU3oTaapFk30nMuZtvEHE2sUg
hyB6Osp2BlW2RiPlNQFbQSXpyACKjA6PJQ81h7yygOnzC3obgDY/KwGzgDZ6a8AuAUvIJGlVK6xG
OC3OrzjJmitdKcQ6vYJZrrgQsSv2ZnJivdFoCgkNa3785J1LpmWa+ELr+u0/+jvUvZbCd107SSjk
Mrl6l/PVh+7+e2dspvXy7htP/PZXsApU1k1GULwzCNKgCXwor9gWfyz+Zvz11J9Sx1M6sCJzVebm
zH2Zx5NPZH6efDbzy+ThzCuNHyU/zLzbaMaTExOYSBuOEFP1vOE2ayDknurnA3cINdW5LOEmwrGa
rOjGybomwpa2wrraNNU0LhYTDGEia4vJWvUp2FfMd95fBatUCIvNWs2gGmBqKX/2NMPcBdvY0x8a
yyq7MtnqC/FUfSovgUIcbRqSdRJsTDSdRTatShCg+H2s4F0tYCvX5jpxR0VQLcgX0oDF1Jo2W0Ol
Ol4FHcu0xKO+WqMteE56TpiN6jCIYaEug8ugu/nHVGNi/Pydvy09c+n8m9uvvmXrD/HdIWcUjmvJ
YLjgNHqNpBlbWljffOpXbXUQE7BcM3NlizcNqSc/gPlTj85NwCevW/7pT3ecQro3PvoFfj6+E9hR
tOIHH8gDS+llxpW2i51XUuvpK4wbrNfYNjg2OE+ZT1hMM+kL6fnWg8SrtneIz5k/WugWtdSXwxk9
xuhxHQr4cIj34DqeX+i3U3fofqLDdG0mg59DBtfP/koP9Sp7g/iHrAp9MFBZ0bIVUARZ5u9IRb+W
xiRcXZsok7jK7AOkM+qVHDZNo/oAF4AejjTjEnBZedSGaENYdFKlCHhMn44tzTsFNXuF5kAtHtIQ
Vx0LQSV6HrvgndIN+heuW3pbi5j4w0+f++VfX3yiGDLDhw2+6kvT+M6Xn/7inUsWG695H/L7X4eR
8YsbzllUPXu8Wu8LAM4iLktgnZzP6yHNePQJBIaEtwJe+iQitPLRT0RcICW7i7Nu5WoNMEgWAn5K
p5OiejwQisN4eWHGL2SpLAJwPxwFsawWxx3+eqDAVlzzkpbzKFQSe5BjD3Jn5cDF+tq6/Fi1oSq/
auhL6fyw1llJzcWXdTz+ePKcD2ffnAv7q/xWsxSe6LOc/Kbl2tJXPNm1Eruu4/4Vv+5uFurElNfp
74u3jXSUrl7dyqhPlxOgQWnHX0L6zA56wblgFnhbXjC+vbfj5vabOnb6SDJO5pkOb0ehYxl+cePD
joc5ps3OZnpTSS/hksI+TJrIttUw6BhPnMtMQ94udm5tbzAxJfFiAk/0TKmd5Q15KGxcwTxrluSa
OO026QFtRR3Ixn6ytiHUn2npirlQSPMb2VzcP72TdeVct7kecBEu1Ub0z84eLmmFv+jf4XdKakp0
LCI8jJAb/GhgUGVUtlQx4WXB1v4XVBOuwmgbSyOoeXP0TzWytjPpBOSbiWM5hFg5qVCrFaQRZRvc
ipWTD/mGSjmwZqNr8defv+Lht2fU3R49J+y6gDNmc7HFP985fmiac6bd+KRNb33+AU+bf153phHC
uXcr2/c8eKC2r92Ycce7Vn8dLS5YfUHUPng+rfxTvnRGB/JOIY5BM9kqN2Cxe+df9psufFpVsKlu
zYvMBcGQRe/P3nf/czeMj3R1Nhtt1mA82r/IEcitm/fXgereK17C+tSaTsTXz5BtzoF9sqvLBb9x
Q8btdWNems0Gc5jYygeH4Um5OazyNxeKeFv5QEhMtvLZkDimdhNiMpkQvVZcF8sRrNMCYuOcVC4b
DOgjYlZdVAX7athYMkvg6uxoK9eaAT+9qnpaxZ4x4lqufgCU1/OikouTXJEAdHNRdywAx9bzVK2a
P+sponGwFbrLxtz9v58yqpywnVPrbzQ4TalrPfOx1urZF/6kOVQ9UZkyq6ZtzuQ76mYqPbyh+RL8
QGM9jkVMUTpAle7tDRc3916mLFkm63ne2HQJ3Lrg8lVWxb6q0ciXbRiSe8yMcDQgH2dAlkSjpdXI
R0MRMRTiQuxUN8/dwYeCrIXgo/RWDPBUNKKPaR5nyLCVjAVDH7MWVdIlbQkW8VbL2LRO0rzMsqlh
v0YKrDpnOyPW9bg2uFjFpKgDHxv2o8VUsqUlmSpuXN7IWHIGZ01yVxdPY/kFipdsGNeivXvSqq+/
DH7c5kkQ5qC54DdSdKlmTRNdHtPoFkWGu7UxZcCNspSi+ZBzqo/n7xCMJkPWKQoZJa4ORqDMC+Pm
pEMdSA6NaY8YyTqc6oJyVhvN56oYqsLXOsKOVVcVzrafgWiVxYpmWWKjloQtACwxWwBaq8zIJY6i
zVhxGpryswePlX2RhvqzbGordJ1e0UWi+ocxFH69UGp1mSD0Zs1pbmZwYbpIpKb+ccKlmQgCY1xS
veibf109PnVR9Hbsjs42PRXk9aLVqaNPLXpywVPFGqFWfRYRycoouRo0gt/Ig92R2aFB543Oh51f
Rr6NUERICklCQygv9Dv6cxeFluXuceqFcLhgc4RFp0MMy+HpNqHa4azOOXOO6uqcGBaQxy4FyiJk
AQEErA40JHCJb8zH9M5q9D7uF3NYrMY/P7YxdiCGx5ryqiwaHNXZxpDhyAFkHFSBaiqoPsvRoyg2
Yd8ZOKi5KmpqXMuNa2umyFYcHzlVTpijP46iWW/SyxbRXqPUWUunZ5iEcLZGtRLKcpLMAt3lsspy
3XJsbO2QmN+SS9t565yLelOUDofOgDPdBHes2vyL5v0/uG2a0iFaeT2jvFEbGK8IPFUzHf+yR8Iw
nvNxFpI59cxxX8joNuI8T/Xtbvj78HrKy2PQaDbYjXCb8oMuZJ4DCPuoJl9XAbf6/K4T4B2Ad4ci
rpDNeIRoMvDG22xWAifQxW6X3qNy0GrL4oQqUVyZg995FLEiSvmzxachXzMmPFUD7QZHi1nwbHqB
wovnKzzPFKbjv273VOl0QqRodJycNquW4it1Kbo6/FEwGXwr8w2euhBmDT1ixqYkphQxtpmdFJyM
t+bTHXziBXgSOf8yVNPARTSLE8NEE+AnhyKRJj4eEvOtfHNIHN/ETwqJxhA5FQ3pDkvHeF9eHt/b
Iecb0hGfgySMXZPtlpquce6accGg20JNnlRsTsT1U1VFYkBSl7k1/XYa600Pwx7Z1C035LNtt8pv
y1ivjM48003YY+OzpIbKlKymgwePDw6oT4KfbpTzQFomSH2cYaRSiVYOICoyW45JrRk4MFBZX/4P
KUTc8UN1hwjy37RxOWal/vPU2BlhsjceSzud5t7YUySJLbxt4kUtIeeE/LyFOxqCrecoLbPyzujF
bXK0oTBXqZ9X5xCWtwym6/uVgpey+2dh5IQMQYqcqVNv3jSnq1tq64uM+96EB5QFPbW0l6cbpsNd
CzLnJD15BUybgXu9xs4bIHdv0wUdDaWPJzZBb2XNFv8T/jNQC+rAM3K/xzvJi91lftiMDGNQYGuC
tVmhVSCjrbwQCqtkrA1F+CY+FBJR7FOjTmGZlZZMOsrbCZyqtVkS49wxC1VbI4T0dVSdFM3WET4e
zdwzDbZYJovjhCrMDfWqdWQ186imG7QywaIqv1Y1GXdmAsgBomwcY3HOG+ck5PB6Y57EGeM4sPq7
9G6F6qz8H4zj6dmA0Z6C0d7M2M2Je86n8Ll1k2d0Nl7c1KnMHN8kn9vcEm6Qu5Q++BHP1M9FLPYi
SRaNNUE9c+e5oerYxJeVdK8MeV7fciF8/NzVcXd96e3eaoxHSOKgbvQPyGfcqT1f5gF3yKlXmM8Y
7C72HtcD7OOur/WkCzgIt3umfgZLNtFcrQejbLW0wePs9BhIFCrs81k6LQZoUKMFn7cSqNkKI2eX
BaSA2xQ1QosE3LhTglYGtewUapkBJ0EXgTas3iYBhw5tzhQEaL7EgBdRFmjPFIB6cPp5wDpMzNeV
Xn0FEqdeO6CcgP1Ni3bcumr9vXdEsbuhXTn1/qvKEeh9F95fd96nTymH33rkSVhTVDnEaD7ybmBE
LDoo9zcwDcJdnnuiO6MPxY7Gvo7R+igZmxDFH47ArggM02yHia89Esl08DWfiFzIqjkNPqNBj5MZ
NpOoTQetRj2JBXz0OJHyUdjChKG2xkx2SlqapD6ASGQ9wEJWpVH52bexNElRs70agaxnfsTg9EPZ
agQbieMUHiclSEXQhohhEtBFaQlWAlg1el2tle6ezorA7xqM0+Q6/VBGhVALLuq++J7tSydcobx0
fm201mC3zSMPkmR7zZx5W179297GhNzQvlKxru343YHhfeelFKb0uK5zPH5gYhJFr0HYyeg2tYca
vzr8mvJzs7NR2b84Q4uVvAHC9wsUg7DIe/21PFOf9CbzSXxr6rHM/szhzAfYF5kTKWpSCjbS0Q5e
+CTs0wQUp6Mmzu3AfTp3zhetEiQHjROsh9PX5iiOYsdVGYSQWReLZr2yD/o059XUuT0N0yrtNOdV
yw8gbP8XsNZaOBZRjBVJJ7OU3YaAtCRNEjBk0Yax6gLQ7jCnWAkYM3qEuF0f0B59q6T7Ko5tpOEs
+dUeLETaFAEdKK9gjUnvmUwMBqaJOQeX3vCDTTddfV6d2LOSQdrT7p+u8P2zumtnLN3wNoS/XM7a
vfE8fHhKaupXd+8+gnfajfF2AhKE4aRc743RvACbFsENXYHqP//+LbUYAAIGgb0b4ZwAm+WJBwMw
H4bBBFS1XgKZrw7VfBlCRCvyY+5gw8EAnoxEwsgYJxx+e2ijH4b8OT/m3+pnY24KGauNXuhN2mOR
cjiwZxciWFX28IBmjg5qC0+Tjh4eWT1QeSD6u2SFA2dVNJ32+iv0qzxCXlnVVVVc3ikwc4vRar1g
K1zurqmncHmdXCtXR6VJLvHCqQOKXaCrp8KXF84kCcFRxdg5Pftg/6KWTKKxe3VRaTm3AxPKXFsy
OoK9jmS5GtRAXBbswA5dWMJUMC0xLjWtN6w3bjbqE3SOr/41Un/oM8Pw9qdRG1liQbaEqzje82vZ
xwveIBq9+h46dKrvJQWbCehp1GOTniCDtTU2iqytMtRYvPBv3lEv5u2m22pALgZjdeFh+E+ZBbFV
lgcsByy4pRvUQfVRkIHBd7iBoyPI90O6cPDgwGoue3rJfcxul6uBPxvQyoHLDzOgU17u+Gfa4w3q
WnylPDgREliVVAk6AEPWcABQcTIABDYYOPNEm7rOXju20K4lF76zzD6WKwzCs9fY4TLBHeve1Der
pnXVlWsfWF9/DW1jdRwVdITHXdY9dcv17+6+tbjNbLSRXhiFzWtaVk1vr5ocldtvPG/VbXG9QfnL
goZF5zbN7e1Ze+/gXXGrEd+PuOlB89JM7ECu1Sy5irFCXxhzYIVAWCcbBH0PNc5ikPWCISIHBBDG
sg4fJ1tTDhSWHv7I+5r3o5aDHFs6eBg12ffQBrSWBt9Rn/hrPaytISPPWF2VEvFKLl17lF59fF4t
HFeDe0Q9lXgYcxgzcd2R+rDXVbe2YbDKvYIkGa6rZbWJxO/tLR2YGOsKR12B7qalhcXY+biO1Bsc
hZ5thOnE2O+QvIvsYhKkwKPy5D6qLziHmhNcQa0Irqfuo+4LMkFT0Iz5aX0Tbw6JUhOfDIkOFFXa
ecdtHt4j+Vk9QybNQIfs5DjBkKL4mD5rSaWirIVFCmxvBsBsVFLtgvrLBJVVcqtWN35UW81oVZfJ
rYXvmARbOIIRuESEkf8tRjARsaCsosqpYTi2jJ4vr5lr0maGyJEISy1Q00raerq6ZheFLfbows62
qFScAzuqp+TrWryzSayzcea8WZMmh1298G/4/aWNnYmJaU8Ki0zKkUJJ7qzFeYvFwYQZ3Y5pseK4
ltswaqrPSvHqT1yCKMLsbXwHEMFD8vkxQ8yZN+Sds+lZ7CzrLHe/vz+whL6Ivch6kXuJfx2zznV5
YBOzybU5cA+4B7ppimaYgg0RmHa7KGq6VspKMS6a9ITDrB2HvFWFMkpTDOPCbMPw1L4ed4ASMT9q
7u25TYTI1X5lYPAU57YWPh4scZrKf0X11FC0peqrSlHqWbWpWuUBMoi+s5bAEVpQe3IxBrXlTjhc
l2QMb+8xuaMuCfLVyYTyKa1n9GZaeSta5cnhO4I6R5j186WT8A2h1x6zMngwSBQuKuXsZrcV+6g/
ZNMFy+uSVaPHyB8gfJogLd8oUVKu4Cz4CkJTWMdQtJm20A4mx4UT4XWOTQ4mhqHgkshjeTxP6Grq
vblcwZbO+XgfX+91ONGU0jSKY9WWbrqtxlePrkinp9vCYSGcztXX+NAFDoF3mjhrNN4IzKSVb4qx
uiBnKDpozMnmWAg0v6Qkm3qcOvQBouDNaYpQPRMqwILEh9OYIAnozN6ekASl5uwrqxHAKpgfs2q+
bnW5PXhqoNx6r5wHPRvwIsUePJhkD1Iq6gdRcIsCXLU1VoZw9gwguGvHJkCK4eWdVo2gFYSoBtYH
83VSuWoWHy42mQz7njLymZTiCfmVA4ROZ8T+qHyDUaQRU96tDmXhmkx1gouu2YMlHY7aDNyBX0d5
Y850QInCp/jz3FGvzu8npZ5TXzG0jsCypd+SFNr/YX2SQpPoSfhXtw0oR+F1RseKZFokKvOIXB2k
G+4GzZCV9/+ZggQgIHACF0xgWSznb5gtzA7PFgddm4hN5D5+n/+Q7vOYrZvqtfSyPW6ioT4v1utp
nb5e56b1+nqX05nQoaHp3AlnPJEX0Rb9b8jX6/Ois2DTJwq2enTZXbqHdPt07+kId9Ym6tD/vJjP
1ydEt1Ovo2uaoMWGN/GstRkHOn+2BvfyfK4a9+nzOr2TaLZaxzer1zZbdb5q1YVqqS5mX/nolQF1
nrKD5Ud/1WruU+5ieaueyGQoMskmB9Ae7dS506aPPUhTqEmpk1qZUfZMWUllosop1rEsBTwrS1HO
3lLlidccprz6E2dI1I5I9fV8stlfXSXB9trZvschXduTURb63UHJFrF2uHf4zcE65f2GuuRfDjSl
JuB389AesM/OdEzLTHB5bTjPE9nYv5RVkzMYz2MYZ7O3hfK++eGT6YDebqR43hAeB6dDcVaI4tW6
KEXG30Q6Xn026CfyJXM8kNK7uXhVIjWB6fRNSJ3rW5LarN+c2pban/pdytybgrGkPpXUau4LNg65
pwwz3ZZKJVOMgfOg9+hsFLM58SxvB7pwtJM356jc2Hs5xgE2OqCjJrgRUUj1Wd8bOMhWZgCpqdLB
1v8UHFVPIbTHZMV+uvSiIi5ZeLbCGjP3Ni0RhACN8vDhGi6jN335HG6K8EFoTyQsyqFz7rq08YLm
tPciV+NVOkI5EK6tgR/hdwchbZLMfn/pG8xAN+q9HIYFg2QmceqF919qbInXogAkxXj12J4JWSpb
9r/qkBzMQvhZgQ08Is91Y69gmGG6DWIQm27T6w0sBanuINIy4ykMsgY9hAaroWDV6fUYgxUYvY3C
0EkblHW8QMdkaheFUeMdxlbZwgvWGDvQs0s/pD+gx/UOu4rW4HHuqPbg1DF28D3kXWle08Fs+XcA
WkvlCtOxfXldajA7oC5VqYAiOMs6f+wnneq1X2ER81G8pfQu9N05WRL5U99gonL84naTSMBZ+N3c
qQN9d1DKV268Y8Ly/7Frv/0Ar8Ouw9XfU+P2AxIef8pgoofh8d2YMftO6TDIIpfNdtaPSvx55+Pr
1z+6cx287okr1u/cuf6KJwAcPQl/hI/CURR9+2ULaMGAl8Q8BHmLsOfH3/kxN4ikAx89eQqOLlyo
4t2Dr8WbySVI1STBdDkpe3AB47BLBGOVLQ5wDLNQnAeL8untCPekc4NlOw/5ZHJD1JvKKqfU36X7
RNseHltYQdpa8ztavB8UOa/2w4OxytLIWT+PcOZH63RjP1OEzuLNt86yL6tyWkzNTLxHbu6apyTv
nGHrWWCwFPVCIFts7Z1L9A3F4i3nVIkGE9VQV9Ox/JwLH5fi6RWtiBk2f0vV+Et6NH2q/X0I+f55
luLX0Eprxwe6Prh/bK9mvam15DXokPn/Wru6mDiqKHzusLszUC67RRDastxdlp/dAjsL26K06TJb
Zxu7FNnCloBUSmtWi7YiRWs1pL+RgkogVknTEts09a816ez0J0tb20YxGmOrDz74E42mtBof1MSo
DzXguRdaY8KDD87m3O/cc8495947d2eYnZnDbXuONphChn4w1Tn1jnzhjub21mD9ENz8Xn+aDhel
E9CBVIP1vYgxxP1SLVgsANlI15FWILUhhZFWIXmRtnI52r1u2Yf6fbA8bQj2yx0wjr4LrS3gQQry
OJbrkGfphTzkq0TcE+BOc0Iul8tOIee0Am3cHLEdt1+H+gKsc3LLQ5CO7c5ItdNXEHWMVY/xZUQV
sQrRi3Lerxreb+yXF21fQN6CfImtFvsBgpYgpfM2aJ+O/diM+gWzYy3BWIsRPUgF6HOJdJWPffoW
8nyP1OBnDCZJNdlBRskV8rO0Rfo4rTXtJ8tBq8u63fagbUrW5H75mtKRHsjIzHhvXsu87zIH6N10
Iqsp67g9077N4XCMzi+aP5Hdd9eynNKcg7mFuZ/nOfIeyNuZdz7/2ILiBebCHYvyF71U8KQzx7mz
0FY4wRzsL9cb7kL3taK9Hovns+Lq4k9K1pdqZcVlE96Qt9Pb5/1R7OEG6AELjOJKkMCBnyqcoB9t
l1FGxKrInl0HNn4fLdYcX92ypjzetTXRW9nUvXXjE7NJ1mE6AYk5k5Q3iBwQVvyGZ4Id/fOjG3+L
D0/w4jeyheJNGicwcIsnR4rFc7Vl4m3mxeJ6oVKcUfCqVPxSuZQ/My4yVi+DENSBBjpEYBXONM8b
HRWZshvgAWiEGKyFJmiGOKwT929boQ0ehHZYDw/BfjDhbArKyjV7+qdxYo+Tus985EicaGFKbuGQ
A6J0idIhSuD3JbhoRCYjNvJruFHic/SLlIblFYlnpzfwKGQgd1lScMynkDuFnARHJE6c24XTtUvi
qMAw8sPI75asiArI0I2SbpR0o6QbJRbYgLUYRtggPDZijUdtFLUA1uqwFhA1FaOpWFNFjUmKiX8W
nyc3SANpOmtn7/VksYuknjTAJmCkyuxvZJfIG+ACSoZFuVfLctFvXfQrFx120V0ueom8iFNIyRZR
Ei0rRr+I0ftitC5Gl8XoBbIc9xElaVqOl77rpSkvfdNL+7x0u5dWerF1EncGJW+K8hXNFaV/RulH
UXowSp+P0uei9JEodUfppgI8l9JFBTRFdp6zv2wfsUM6smdG6MsjKPv9dJXKwiny29kgK6+oYSky
aMYrEPaZ8ZMsnEv2gM/Cn/DdDT6JYx/oAp8lAYE7SEDonzFVHzbrNUOvIfSYoUmcjsfBL5SPmcFJ
lN5rxjtYOJ0EZ31Wg65wrDRDB1C92Ky4ysLzSRn4SQmKiyEo1B4ICvOiWbSZ8VI0t57Bjk77UoSY
bGogJZFz7JbaxP7wpywo+d2fUhC+96Wkkyb7RkXQ8tjXagf7MhRlE+jh/fgku6xuYecrRIO39Yvc
O7xFAuSQNo+9rh5gx9VBdiwk1EeDwt9oXMCrPhSeY4PoptefIi0m2xbkEeaxx9HjYxX17GEUH9Ls
zF9xD2tWL7C16jbWOBNptS7gfvW8GM5vGg07WVh1shWhq2y5jiMxWS1vbrIlM8Gr/WJ4VaE1rByH
ZznHFserWBGGJFolW/eovEFeJ98jL5UDcqlcIhfKTjlHyVYceJWWqWQoimJTLAquWyUnNf2dVs4P
Ozk2BwebRWRIFbxDuv1PHfgjoESRcGnxnNAGGbp7e11+XXZofu0qfY6ic7Ysn2tzGqP1za3GCWeb
Uc2ZaWdbvbGUJ+AeJz+QGxF9nNzk0IZ1N/kh0iTkbr2tLb/eWBNrTZGbka4UKro2GhpX3kSBoW1E
g3qjRfgBH4r0cYhzQD9SDfi4H1yyNcJscMZMRS9opnPgZpOgCjNVmhRmV7lZcsAX0ZM+nzCx+mFA
mAxY/dwEJ3ym5wFsqidVVVhlGCQg+h3IMIQjp3AUDKJJKMhNktVBNEgGq4Va/UddMaNumlE3CXX7
P2r/jProjPooqsv/py2x8r/ZnW4/vGeMZ0Tv9EQSSJ3Gi9s35xu7N7lcyT2HZ1Oll3Zuengzx40J
47AnoRt7PLor2T42h3qMq9s9ehLGIvHW5JiW0M12rV0kUj/dP9QT+VeswTuxeobmcDbEnfXwWP2R
OdQRru7nsSI8VoTH6tf6RSw+tkhX88reObannn66o7e3A/4GBaDh2gplbmRzdHJlYW0KZW5kb2Jq
CjgwIDAgb2JqCjE5MzUxCmVuZG9iago4MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3Ig
L0FzY2VudCA3NTAgL0NhcEhlaWdodCA2NjkgL0Rlc2NlbnQgLTI1MCAvRmxhZ3MKMzIgL0ZvbnRC
Qm94IFsgLTIwNCAtNDI5IDE3MDEgMTI3MiBdIC9Gb250TmFtZSAvUFNUSVZMK1RpbWVzLVJvbWFu
Ci9JdGFsaWNBbmdsZSAwIC9TdGVtViAwIC9NYXhXaWR0aCAxNzIxIC9YSGVpZ2h0IDQ1NCAvRm9u
dEZpbGUyIDc5IDAgUgo+PgplbmRvYmoKODIgMCBvYmoKWyAyNTAgNzIyIDQwOCA3MjIgNzIyIDcy
MiA3MjIgNzIyIDMzMyAzMzMgNzIyIDcyMiAyNTAgMzMzIDI1MCAyNzggNTAwCjUwMCA1MDAgNTAw
IDcyMiA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCA3MjIgNTY0IDcyMiA1NjQgNDQ0IDkyMSA3MjIK
NjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1
NTYgNzIyIDY2Nwo1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNzIyIDMzMyAyNzggMzMzIDcy
MiA3MjIgNzIyIDQ0NCA1MDAgNDQ0CjUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4
IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzgKNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQg
NzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcyMiA3
MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcy
MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgMzUw
IDcyMiA3MjIKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg
NzIyIDcyMiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3
MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDUw
MCA3MjIgNzIyIDQ0NCBdCmVuZG9iago2IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9U
cnVlVHlwZSAvQmFzZUZvbnQgL1BTVElWTCtUaW1lcy1Sb21hbiAvRm9udERlc2NyaXB0b3IKODEg
MCBSIC9XaWR0aHMgODIgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMSAvRW5jb2Rpbmcg
L01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjgzIDAgb2JqCjw8IC9BdXRob3IgKEN5cnVzIERh
Ym9vKSAvQ3JlYXRvciAoUG93ZXJQb2ludCkgL0NyZWF0aW9uRGF0ZSAoRDoyMDA2MDMyMTEwMjYw
Ni0wNicwMCcpCi9Nb2REYXRlIChEOjIwMDYwMzIxMTAyNjA2LTA2JzAwJykgL1Byb2R1Y2VyIChN
YWMgT1MgWCAxMC40LjUgUXVhcnR6IFBERkNvbnRleHQpCi9UaXRsZSAoRGFsbGFzLnBwdCkgPj4K
ZW5kb2JqCnhyZWYKMCA4NAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDA1NDcgMDAwMDAgbiAK
MDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAwNjUxIDAwMDAwIG4gCjAwMDAwMDA1MjggMDAwMDAg
biAKMDAwMDAwMTU3NSAwMDAwMCBuIAowMDAwMDQxODA0IDAwMDAwIG4gCjAwMDAwMTU1MDEgMDAw
MDAgbiAKMDAwMDAwMDc0OSAwMDAwMCBuIAowMDAwMDAxNTU2IDAwMDAwIG4gCjAwMDAwMDI2Nzkg
MDAwMDAgbiAKMDAwMDAwMTYxMCAwMDAwMCBuIAowMDAwMDAyNzg2IDAwMDAwIG4gCjAwMDAwMDI2
NTkgMDAwMDAgbiAKMDAwMDAwMzc1MiAwMDAwMCBuIAowMDAwMDAyODg1IDAwMDAwIG4gCjAwMDAw
MDM4NTkgMDAwMDAgbiAKMDAwMDAwMzczMiAwMDAwMCBuIAowMDAwMDA0NTY0IDAwMDAwIG4gCjAw
MDAwMDM5NTggMDAwMDAgbiAKMDAwMDAwNDY3MSAwMDAwMCBuIAowMDAwMDA0NTQ0IDAwMDAwIG4g
CjAwMDAwMDUxMTIgMDAwMDAgbiAKMDAwMDAwNDc3MCAwMDAwMCBuIAowMDAwMDA1MjE5IDAwMDAw
IG4gCjAwMDAwMDUwOTIgMDAwMDAgbiAKMDAwMDAwNTc5OCAwMDAwMCBuIAowMDAwMDA1MzE4IDAw
MDAwIG4gCjAwMDAwMDU5MDUgMDAwMDAgbiAKMDAwMDAwNTc3OCAwMDAwMCBuIAowMDAwMDA3MDQ1
IDAwMDAwIG4gCjAwMDAwMDYwMDQgMDAwMDAgbiAKMDAwMDAwNzE1MyAwMDAwMCBuIAowMDAwMDA3
MDI1IDAwMDAwIG4gCjAwMDAwMTU2MTAgMDAwMDAgbiAKMDAwMDAwODIyMyAwMDAwMCBuIAowMDAw
MDA3MjUyIDAwMDAwIG4gCjAwMDAwMDgzMzEgMDAwMDAgbiAKMDAwMDAwODIwMyAwMDAwMCBuIAow
MDAwMDA4ODg1IDAwMDAwIG4gCjAwMDAwMDg0MzAgMDAwMDAgbiAKMDAwMDAwODk5MyAwMDAwMCBu
IAowMDAwMDA4ODY1IDAwMDAwIG4gCjAwMDAwMDk5NjYgMDAwMDAgbiAKMDAwMDAwOTA5MiAwMDAw
MCBuIAowMDAwMDEwMDc0IDAwMDAwIG4gCjAwMDAwMDk5NDYgMDAwMDAgbiAKMDAwMDAxMTAxMyAw
MDAwMCBuIAowMDAwMDEwMTczIDAwMDAwIG4gCjAwMDAwMTExMjEgMDAwMDAgbiAKMDAwMDAxMDk5
MyAwMDAwMCBuIAowMDAwMDExNjU3IDAwMDAwIG4gCjAwMDAwMTEyMjAgMDAwMDAgbiAKMDAwMDAx
MTc2NSAwMDAwMCBuIAowMDAwMDExNjM3IDAwMDAwIG4gCjAwMDAwMjExOTYgMDAwMDAgbiAKMDAw
MDAxMjQ5OCAwMDAwMCBuIAowMDAwMDExODc3IDAwMDAwIG4gCjAwMDAwMTI2MDYgMDAwMDAgbiAK
MDAwMDAxMjQ3OCAwMDAwMCBuIAowMDAwMDE1NzIxIDAwMDAwIG4gCjAwMDAwMTMxNDkgMDAwMDAg
biAKMDAwMDAxMjcwNSAwMDAwMCBuIAowMDAwMDEzMjU3IDAwMDAwIG4gCjAwMDAwMTMxMjkgMDAw
MDAgbiAKMDAwMDAxNDc0NCAwMDAwMCBuIAowMDAwMDEzMzU2IDAwMDAwIG4gCjAwMDAwMTQ4NTIg
MDAwMDAgbiAKMDAwMDAxNDcyMyAwMDAwMCBuIAowMDAwMDE1Mjk0IDAwMDAwIG4gCjAwMDAwMTQ5
NTEgMDAwMDAgbiAKMDAwMDAxNTQwMiAwMDAwMCBuIAowMDAwMDE1Mjc0IDAwMDAwIG4gCjAwMDAw
MTU4MTggMDAwMDAgbiAKMDAwMDAxNTkxNyAwMDAwMCBuIAowMDAwMDE1OTY4IDAwMDAwIG4gCjAw
MDAwMjA3NjAgMDAwMDAgbiAKMDAwMDAyMDc4MSAwMDAwMCBuIAowMDAwMDIxMDA4IDAwMDAwIG4g
CjAwMDAwMjEzNzEgMDAwMDAgbiAKMDAwMDA0MDgxMyAwMDAwMCBuIAowMDAwMDQwODM1IDAwMDAw
IG4gCjAwMDAwNDEwNjQgMDAwMDAgbiAKMDAwMDA0MTk4MCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9T
aXplIDg0IC9Sb290IDc0IDAgUiAvSW5mbyA4MyAwIFIgL0lEIFsgPDkxNjgyNGJjOWI5YWI3MDEw
ZGQ5ZGVjN2Q2MTY1ZGM0Pgo8OTE2ODI0YmM5YjlhYjcwMTBkZDlkZWM3ZDYxNjVkYzQ+IF0gPj4K
c3RhcnR4cmVmCjQyMTg3CiUlRU9GCg==

--==========AEEB27AEED0558C25DA0==========--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LFt8EN077036; Tue, 21 Mar 2006 08:55:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LFt8f4077035; Tue, 21 Mar 2006 08:55:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LFt7mc077029 for <[e-mail]>; Tue, 21 Mar 2006 08:55:07 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 21 Mar 2006 15:52:50 +0000
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 07:52:45 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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:

>> 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>>    when working with an IMAP store?
>>    
>>
>Somehow the question does not sound right to me, see below.
>  
>
>>   Implementations MAY place restrictions on
>>   folder names; use of an invalid folder name MAY be treated as an
>>   error or result in delivery to an implementation-defined folder.
>>    
>>
>That is a very good path between all alternatives and I like it as it
>is.
>  
>
>>Should it say more than this in either direction?  I pondered adding
>>text about mapping UTF-8 to mUTF-7 and a supporting example (the
>>the open issues entry), but it couldn't find a wording that didn't
>>feel like one step too far beyond the scope of sieve.
>>    
>>
>
>I would appreciate a requirement that says: If the implementation uses
>a different unicode encoding scheme than UTF-8 for folder names, it MUST
>translate the folder name from UTF-8 to its encoding scheme.
>  
>
I like that.
UTF-8 to mUTF7 can be given as an informative example.

>It would fit into the general picture of Sieve that uses UTF-8 everywhere
>and relies on the implementation to convert.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LFn2p6076776; Tue, 21 Mar 2006 08:49:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LFn2HP076775; Tue, 21 Mar 2006 08:49:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LFn1QT076768 for <[e-mail]>; Tue, 21 Mar 2006 08:49:01 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 21 Mar 2006 15:48:53 +0000
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 07:48:48 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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>

Philip Guenther wrote:

>To either head-off or prime the conversation for tomorrow...
>
>draft-ietf-sieve-3028bis-06.txt
>-------------------------------
>
>The primary issue for the base-spec has been whether it's description
>of matching is inline with that description in the collation doc,
>draft-newman-i18n-comparator.  I _believe_ the current drafts are
>in agreement on the details.  Either confirmation or corrections
>from others are needed.
>  
>
I think you've missed a couple of issues I've reported:
1). I can't see any text about stripping leading/trailing whitespaces 
(text moved from the relational extension)
2). I think IANA template is not precisely defined, I am not clear on 
what is the difference between "capability name" and "capability 
keyword"? Is the former supposed to be a human readable phrase? Also, 
what should be put into "Capability arguments" if an extension supports 
multiple actions/tests.

>I've made one tweak for the next rev to the wording in section 2.7.1
>regarding ':match' and the definition of 'character'; I had overlooked
>an off-list comment at the turn of the year.  The paragraph now
>reads:
>   The ":matches" match type specifies a wildcard match using the
>   characters "*" and "?"; the entire value must be matched.  "*"
>   matches zero or more characters in the value and "?" matches a single
>   character in the value, where the comparator that is used (see 2.7.3)
>   defines what a character is.  For example, the comparators "i;octet"
>   and "en;ascii-casemap" define a character to be a single octet so "?"
>  
>
I don't think en;ascii-casemap is working on octets. So either the 
comparators draft need to be changed, or this sentence need to be changed.

>   will always match exactly one octet when one of those comparators is
>   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>   defines a character to be any UTF-8 octet sequence encoding one
>   Unicode character and thus "?" may match more than one octet.  "?"
>   and "*" may be escaped as "\\?" and "\\*" in strings to match against
>   themselves.  The first backslash escapes the second backslash;
>   together, they escape the "*".  This is awkward, but it is
>   commonplace in several programming languages that use globs and
>   regular expressions.
>
>
>As listed in the doc, the open issues are:
>  
>
My personal answers (chair hat off) to these questions:

> 1) is 'reject' going back in here as a "do the the best you can" action?
>  
>
I would rather keep it separate, as reject is still going through 
massive changes.

> 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>    when working with an IMAP store?
>  
>
Yes please.

>The latter thought actually came about from pondering the description
>of fileinto after a suggestion that all the fileinto examples in
>spec should use a consistent style of folder naming (e.g., always
>using a prefix of "INBOX.").  I felt it better to leave the spec
>mixed, if just to avoid the implication that a particular style was
>meant to be mandated.
>
I agree.

>Indeed, I went ahead and inserted the text
>in section 4.1:
>   Implementations MAY place restrictions on
>   folder names; use of an invalid folder name MAY be treated as an
>   error or result in delivery to an implementation-defined folder.
>  
>
Yes, the text should be carefully worded to make it clear that this 
restriction is on mailstores supporting IMAP.

>Should it say more than this in either direction?  I pondered adding
>text about mapping UTF-8 to mUTF-7 and a supporting example (the
>the open issues entry), but it couldn't find a wording that didn't
>feel like one step too far beyond the scope of sieve.
>
>
>draft-ietf-sieve-body-03.txt
>----------------------------
>
>This had been blocked pending the settling of the comparator/charset
>wording in the base spec.  Again, I believe it to be in agreement
>but confirmation is needed.  At that point, this can be put into
>the submission queue behind the 3028bis.
>
>
>draft-ietf-sieve-editheader-04.txt
>----------------------------------
>
>This has been reading for submission for a while; I think the
>write-up is even done.  This last rev was basically editorial.
>  
>
(Chair hat on): The draft needs to address the issue with 
leading/trailing spaces.
Also there might be some interaction with reject I would like to discuss 
(I will send a separate email on this).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LEQxlc072919; Tue, 21 Mar 2006 07:26:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LEQxMt072918; Tue, 21 Mar 2006 07:26:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LEQwXM072911 for <[e-mail]>; Tue, 21 Mar 2006 07:26:58 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.242] (helo=mx9.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FLhp2-0007VY-VF for [e-mail]; Tue, 21 Mar 2006 15:26:56 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx9.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #1) id 1FLhp2-00025c-Rs for [e-mail]; Tue, 21 Mar 2006 15:26:56 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61-RC1 #1) id 1FLhoy-00019Y-Fg for [e-mail]; Tue, 21 Mar 2006 15:26:52 +0100
Date: Tue, 21 Mar 2006 15:26:52 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: document status: 3028bis, body, editheader
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 Mon, Mar 20, 2006 at 10:59:50PM -0800, Philip Guenther wrote:
> I've made one tweak for the next rev to the wording in section 2.7.1
> regarding ':match' and the definition of 'character'; I had overlooked
> an off-list comment at the turn of the year.  The paragraph now
> reads:

Sounds very good to me.

>  2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>     when working with an IMAP store?

Somehow the question does not sound right to me, see below.

>    Implementations MAY place restrictions on
>    folder names; use of an invalid folder name MAY be treated as an
>    error or result in delivery to an implementation-defined folder.

That is a very good path between all alternatives and I like it as it
is.

> Should it say more than this in either direction?  I pondered adding
> text about mapping UTF-8 to mUTF-7 and a supporting example (the
> the open issues entry), but it couldn't find a wording that didn't
> feel like one step too far beyond the scope of sieve.

I would appreciate a requirement that says: If the implementation uses
a different unicode encoding scheme than UTF-8 for folder names, it MUST
translate the folder name from UTF-8 to its encoding scheme.

It would fit into the general picture of Sieve that uses UTF-8 everywhere
and relies on the implementation to convert.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2L6xqaZ054702; Mon, 20 Mar 2006 23:59:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2L6xqN8054701; Mon, 20 Mar 2006 23:59:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2L6xqx1054695 for <[e-mail]>; Mon, 20 Mar 2006 23:59:52 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2L6xoQP013031 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Mon, 20 Mar 2006 22:59:51 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2L6xoQP013031
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142924391; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:From:To:Subject:Date:Sender; b=SSqFMnc0IrzDKapZ23MbSYbXt JrY4kFWNVgtIx8ddLwSFYcLXAfby6wBfckM8gVLt10UHWJtmd2g5omArYhrZrjk/8uq fOEZ18h9o0cREG+NcQV5htjq3AC02vUKdkeY+Hg4l7ovuzvaUnKWQrOB9o8/EcjZkCL w3HD4n1zWbJQ=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2L6xoQP013031
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:from:to:subject:date:sender; b=uMuT1hkU83NJtOLun0yxH+Th8X67SCfM5nDVoVZFMUE7iWaJ6W7DpjOSlqcQcWay1 LZ876PMC8qo5afTaICq2f0L0QSv1LqpprbYhZEe6UAcgYZ+j+CQPChBOUG/Vt2vvuCl ej25pqZjziNTg3A2eJKFNyqGNrT+Lk14dhXRRcc=
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 k2L6xogG099462 for <[e-mail]>; Mon, 20 Mar 2006 22:59:50 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Philip Guenther <[e-mail]>
To: [e-mail]
Subject: document status: 3028bis, body, editheader
Date: Mon, 20 Mar 2006 22:59:50 -0800
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>

To either head-off or prime the conversation for tomorrow...

draft-ietf-sieve-3028bis-06.txt
-------------------------------

The primary issue for the base-spec has been whether it's description
of matching is inline with that description in the collation doc,
draft-newman-i18n-comparator.  I _believe_ the current drafts are
in agreement on the details.  Either confirmation or corrections
from others are needed.

I've made one tweak for the next rev to the wording in section 2.7.1
regarding ':match' and the definition of 'character'; I had overlooked
an off-list comment at the turn of the year.  The paragraph now
reads:
   The ":matches" match type specifies a wildcard match using the
   characters "*" and "?"; the entire value must be matched.  "*"
   matches zero or more characters in the value and "?" matches a single
   character in the value, where the comparator that is used (see 2.7.3)
   defines what a character is.  For example, the comparators "i;octet"
   and "en;ascii-casemap" define a character to be a single octet so "?"
   will always match exactly one octet when one of those comparators is
   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
   defines a character to be any UTF-8 octet sequence encoding one
   Unicode character and thus "?" may match more than one octet.  "?"
   and "*" may be escaped as "\\?" and "\\*" in strings to match against
   themselves.  The first backslash escapes the second backslash;
   together, they escape the "*".  This is awkward, but it is
   commonplace in several programming languages that use globs and
   regular expressions.


As listed in the doc, the open issues are:
 1) is 'reject' going back in here as a "do the the best you can" action?
 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
    when working with an IMAP store?

The latter thought actually came about from pondering the description
of fileinto after a suggestion that all the fileinto examples in
spec should use a consistent style of folder naming (e.g., always
using a prefix of "INBOX.").  I felt it better to leave the spec
mixed, if just to avoid the implication that a particular style was
meant to be mandated.  Indeed, I went ahead and inserted the text
in section 4.1:
   Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.

Should it say more than this in either direction?  I pondered adding
text about mapping UTF-8 to mUTF-7 and a supporting example (the
the open issues entry), but it couldn't find a wording that didn't
feel like one step too far beyond the scope of sieve.


draft-ietf-sieve-body-03.txt
----------------------------

This had been blocked pending the settling of the comparator/charset
wording in the base spec.  Again, I believe it to be in agreement
but confirmation is needed.  At that point, this can be put into
the submission queue behind the 3028bis.


draft-ietf-sieve-editheader-04.txt
----------------------------------

This has been reading for submission for a while; I think the
write-up is even done.  This last rev was basically editorial.



Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KGPxSe017974; Mon, 20 Mar 2006 09:25:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KGPxrD017973; Mon, 20 Mar 2006 09:25:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KGPws3017967 for <[e-mail]>; Mon, 20 Mar 2006 09:25:59 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.132.136] (DHCP-Wireless-132-136.ietf65.org [130.129.132.136])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 20 Mar 2006 16:25:55 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Mar 2006 08:25:49 -0800
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Jabber server for IETF has moved
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>

For people who want to participate in the Sieve meeting remotely, please 
read:
<http://www.ietf.org/meetings/text_conf.html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28KoERA064837; Wed, 8 Mar 2006 13:50:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k28KoEhO064836; Wed, 8 Mar 2006 13:50:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28KoDfx064813 for <[e-mail]>; Wed, 8 Mar 2006 13:50:14 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko20e006038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002pm-Fm; Wed, 08 Mar 2006 15:50:02 -0500
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-3028bis-06.txt 
Message-Id: <[e-mail]>
Date: Wed, 08 Mar 2006 15:50:02 -0500
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 Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-06.txt
	Pages		: 38
	Date		: 2006-3-8
	
This document describes a language for filtering email messages at
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 Message Access Protocol (IMAP) servers, as it has no
variables, loops, or ability to shell out to external programs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-06.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-3028bis-06.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-3028bis-06.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-3028bis-06.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28KoCfs064828; Wed, 8 Mar 2006 13:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k28KoCwI064827; Wed, 8 Mar 2006 13:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28KoChL064812 for <[e-mail]>; Wed, 8 Mar 2006 13:50:12 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko29W006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002q1-I2; Wed, 08 Mar 2006 15:50:02 -0500
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-body-03.txt 
Message-Id: <[e-mail]>
Date: Wed, 08 Mar 2006 15:50:02 -0500
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: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-03.txt
	Pages		: 12
	Date		: 2006-3-8
	
This document defines a new primitive for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-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-body-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-body-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-body-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-body-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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28Ko9Oa064820; Wed, 8 Mar 2006 13:50:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k28Ko9B3064819; Wed, 8 Mar 2006 13:50:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k28Ko95F064811 for <[e-mail]>; Wed, 8 Mar 2006 13:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko29W006304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002q6-Iv; Wed, 08 Mar 2006 15:50:02 -0500
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-04.txt 
Message-Id: <[e-mail]>
Date: Wed, 08 Mar 2006 15:50:02 -0500
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-04.txt
	Pages		: 9
	Date		: 2006-3-8
	
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-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-editheader-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-editheader-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-editheader-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27Lb1Zj000997; Tue, 7 Mar 2006 14:37:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k27Lb1Uf000996; Tue, 7 Mar 2006 14:37:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k27LaxM2000989 for <[e-mail]>; Tue, 7 Mar 2006 14:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 81176 invoked by uid 101); 7 Mar 2006 16:36:58 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 7 Mar 2006 16:36:58 -0500
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
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 Mon, Mar 06, 2006 at 12:06:31AM +0100, Michael Haardt wrote:
> 
> As it is, all kinds of subadressing are in use, and given the broad range
> of possibilities, this extension almost certainly can not be used for all
> of them.  To begin with, it would only allow a single separator character
> and suffix details.  I showed some people use character sequences as
> separator and some use the detail as prefix.  Now the extension covers
> those cases, but that does not mean it covers everything.  That's why
> I vote for a system-defined method of determining user and detail part.

Me too.. I think the functionality of this extension is diminished by
specifying particular syntaxes of user and detail.  After all, it seems
to me that one thing this extension is trying to do is remove knowledge
of those syntax details from the script writer; this becomes more useful
with less simplistic localpart formations.

I think it's fine if the spec focuses on a couple of different styles of
subaddressing for the purposes of explanation and exposition.  But I
don't really know why you'd want to mandate whatever we can think up at
the moment as being the only ways addresses can be extended.  The
interpretation of the localpart is best left up to any implementation,
and not just in the ways that we know of now.

I could imagine having hashed addresses:  let's say
"b0359d533e48623bae1d2dad9f2aedc4" corresponds to mem-foo .  Or perhaps
"nfmoioesoee" would be mem-foo with some noise thrown in.  Seems to me
that a subaddress extension would be much more useful to these cases
than for the simple substring/separator cases being discussed (since
difficult uses better illustrate how the extension removes the burden of
decoding them from the user, and leaves it to the implementation).


While I'm here, re this comment upthread:

On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> My interpretation is that for that example address, the sieved handling
> mail for silverton.berkeley.edu would follow the qmail practice and
> split the localpart on the first '-', such that :user would specify
> 'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
> disagree or desire otherwise, please describe the additional (or
> alternative) processing you're looking for.

This brings up the fact that there are already user/detail formations
out there that are not as simplistic as they might appear.  qmail
actually doesn't split on the first '-' or whatever character is in use.
It splits according to one of its control files that allows the base
"user" and detail parts to be determined.  In a default installation the
hyphen separates the two, but you can't just look for the first one.  A
base user part can be "mem-of-nh" and it's completely legitimate to have
a detail of "for-my-house" with "mem-of-nh-for-my-house" being the
complete localpart.

One might think that you could look for the final recipient address in
that string, but not with any great reliability- the base user part in
the string does not have to be the same as the one that is delivered to.

Also, the user control file can (in effect) specify different
user/detail separator strings per user or even per detail per user.
It's not common for different separators for different users in a qmail
environment, but it's possible and it's done now and then.

Having done the basic split, qmail will look for subdetail splits in the
suffix, using a hardwired separator character, usually hyphen.  (I think
I have mentioned in the past that having only one detail level doesn't
completely satisfy there as it's common to use subdetail delegation.)  A
user part of "mem" could have different separator and detail formats
including "mem-first" and "mem..second" and "mem+third" .  (Or, indeed,
"mem-sieve" and "mem..sieve" and "mem+sieve" all of which are
different.)  Just to be clear, I'm not talking about aliases: I'm
talking about a particular user being able to use any detail string
using those formats.)

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k267oFQP090445; Mon, 6 Mar 2006 00:50:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k267oFFJ090444; Mon, 6 Mar 2006 00:50:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k267oEWG090427 for <[e-mail]>; Mon, 6 Mar 2006 00:50:14 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k267o1BX007537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 07:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGATh-0008Lp-R8; Mon, 06 Mar 2006 02:50:01 -0500
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-refuse-reject-01.txt 
Message-Id: <[e-mail]>
Date: Mon, 06 Mar 2006 02:50:01 -0500
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		: The SIEVE mail filtering language - reject and refuse extensions
	Author(s)	: M. Elvey, A. Melnikov
	Filename	: draft-ietf-sieve-refuse-reject-01.txt
	Pages		: 0
	Date		: 2006-3-5
	
This memo defines the SIEVE mail filtering language (RFC
   <<3028bis>>) "reject" extension.
   
   A Joe-job is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by the bounces,
   Message Disposition Notifications (MDNs) and messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to
   the flood of Joe-job spam to victims of Joe-jobs.  This document
   updates definition of "reject" to allow for rejecting messages
   during the SMTP transaction.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-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-refuse-reject-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-refuse-reject-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-refuse-reject-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25N6btG068035; Sun, 5 Mar 2006 16:06:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k25N6bAe068034; Sun, 5 Mar 2006 16:06:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25N6ZgY068028 for <[e-mail]>; Sun, 5 Mar 2006 16:06:36 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FG2J8-0007ia-KJ for [e-mail]; Mon, 06 Mar 2006 00:06:34 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #60) id 1FG2J8-000840-I2 for [e-mail]; Mon, 06 Mar 2006 00:06:34 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #1) id 1FG2J5-0000z8-Oa for [e-mail]; Mon, 06 Mar 2006 00:06:31 +0100
Date: Mon, 6 Mar 2006 00:06:31 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
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 Sat, Mar 04, 2006 at 10:50:44PM -0800, Philip Guenther wrote:
> I guess my concern is that generalizing the wording will make it less
> precise and more difficult to understand.  Currently there are some
> fairly precise statements setting when :detail is or contains the empty
> key; if this all becomes just a system-defined abstract query, how can
> those requirements still be stated?

They can't, and I don't see why they should.  If subaddressing would be
specified by any standard, things would be different, but it is not.

Trying to standardize subadressing by creating a sieve extension that
is able to process a (large, but still a) subset of what is possible
does not look right to me.  If you want to define how subadressing
should work, for cleaning up the world-wide mess, then it should be
done outside the context of Sieve (perhaps as common best practice),
not by trying to set facts.

As it is, all kinds of subadressing are in use, and given the broad range
of possibilities, this extension almost certainly can not be used for all
of them.  To begin with, it would only allow a single separator character
and suffix details.  I showed some people use character sequences as
separator and some use the detail as prefix.  Now the extension covers
those cases, but that does not mean it covers everything.  That's why
I vote for a system-defined method of determining user and detail part.

To satisfy all needs, Exim sets the user and the detail part by generic
string expressions.  I will not cripple that to specify a separator
and a matching direction, but using that flexibility to express more
is obviously a violation of the extension that requires user and detail
part to be substrings - not something I am glad about.

Please don't focus on VERP.  I just quoted it because it was the first
application of subadressing not using substrings that came to my mind.
I am sure there is more, but I do not have a reference for crypted detail
parts or something like that.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25GZqB0052519; Sun, 5 Mar 2006 09:35:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k25GZqI0052518; Sun, 5 Mar 2006 09:35:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([209.55.107.55]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25GZmMc052512 for <[e-mail]>; Sun, 5 Mar 2006 09:35:51 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 5 Mar 2006 08:35:46 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1141576546; h=Date: 	 From:Subject:MIME-version; b=GISp5vz0H0QjjpVtOXx2ROTSmhaTAZgtEFH65C OSsvJ2El70cDkOPmOeZdnbka6swBUjFDp5SuTWMhzPsWtxwA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 05 Mar 2006 08:35:44 -0800 (PST)
Cc: Michael Haardt <[e-mail]>, [e-mail]
To: Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 05 Mar 2006 08:25:40 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
In-reply-to: "Your message dated Sat, 04 Mar 2006 22:50:44 -0800" <[e-mail]>
MIME-version: 1.0
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>

> Michael Haardt <[e-mail]> writes:
> >On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> ...
> >> I didn't think VERPs were an all-or-nothing choice.  A user may send
> >> some messages with VERP-style address and others with random tags in the
> >> subaddress portion.  Please explain how a system that 'decoded' VERPs
> >> would support that.
> >
> >Users usually do not send VERPs, but MLMs do.  The system that runs
> >the MLM would be configured to know which bounces belong to the MLM,
> >and set up subaddressing to decode VERP.  Mail that belongs to users
> >would be delivered with subaddressing set up as the local convention
> >for users is, i.e. <user+detail@domain>.

> So, the use-case you have in mind for the requested flexibility would be
> for sieve scripts running 'in front of' MLMs only?  That's a pretty
> specialized application.

I agree. I will also point out, again, that the VERP concept is distinct from
the specific encoding that's described, and may be MLM or even list specific.
It may make sense, for example, to incorporate some sort of keying mechanism to
prevent forged unsubscribes.

> >> VERPs are a optional encoding inside the subaddress encoding, ergo
> >> decoding of them should be separately performed or requested so that
> >> access to both levels can be provided.
> >
> >If you want ultimate configurability, indeed variables and string
> >expressions are needed.  But all I ask for is making the subaddress
> >specification less restrictive on issues outsides its scope and change
> >it into an abstraction that simply queries an abstract user and detail
> >part, not caring about how they are formed.

> I guess my concern is that generalizing the wording will make it less
> precise and more difficult to understand.  Currently there are some
> fairly precise statements setting when :detail is or contains the empty
> key; if this all becomes just a system-defined abstract query, how can
> those requirements still be stated?

I'm afraid I have to agree. Breaking the local-part apart into pieces
is one thing, decoding any encoding in there is quite another.

If you want a different example, consider how you'd embed a non-ASCII folder
name in a subaddress. The situation surrounding IMAP's use of modified UTF-7 is
already enough of a mess without allowing for decoding to occur as
part of sieve subaddress handling.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k256opUI029646; Sat, 4 Mar 2006 23:50:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k256opsY029645; Sat, 4 Mar 2006 23:50:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k256oofk029639 for <[e-mail]>; Sat, 4 Mar 2006 23:50:50 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k256oigv014358 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 4 Mar 2006 22:50:44 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k256oigv014358
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1141541446; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:Subject:In-reply-to:References:Date:From; b=gRTu5K kDg6/GLRd3bIULehBoiTmYcw43Lpdl+omfQVDyyyHr63iPu0yypCFW2Thrgm1FYiSCI iL8AYoSY1NuxokNObnAqZY0v/s0cEWrwQLemBvHmiRF7GNaILQJALahqvmZH6TvDu3v Ghr+dzyiNRT8v0WZ6JmMIpAD+2DXaCc=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k256oigv014358
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:subject:in-reply-to:references:date:from; b=OWAsp0Qf1C0firi2uXoicv0Wh0RvYEop4BRs64JdBrjFzDC+VL6nHVUjWXaWZt8Re d8obKHPDetvQ8thys/Q1G8E5NcGYgAIsYSXdEVk0ep8RutFir9S893AEvuhNy5/bDBk BNxKs3IxiXHpJeKO0/po2ktQDp/gMynxofU66kQ=
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 k256oiU6022888; Sat, 4 Mar 2006 22:50:44 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Sat, 04 Mar 2006 22:50:44 -0800
From: Philip Guenther <[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>

Michael Haardt <[e-mail]> writes:
>On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
...
>> I didn't think VERPs were an all-or-nothing choice.  A user may send
>> some messages with VERP-style address and others with random tags in the
>> subaddress portion.  Please explain how a system that 'decoded' VERPs
>> would support that.
>
>Users usually do not send VERPs, but MLMs do.  The system that runs
>the MLM would be configured to know which bounces belong to the MLM,
>and set up subaddressing to decode VERP.  Mail that belongs to users
>would be delivered with subaddressing set up as the local convention
>for users is, i.e. <user+detail@domain>.

So, the use-case you have in mind for the requested flexibility would be
for sieve scripts running 'in front of' MLMs only?  That's a pretty
specialized application.


>> VERPs are a optional encoding inside the subaddress encoding, ergo
>> decoding of them should be separately performed or requested so that
>> access to both levels can be provided.
>
>If you want ultimate configurability, indeed variables and string
>expressions are needed.  But all I ask for is making the subaddress
>specification less restrictive on issues outsides its scope and change
>it into an abstraction that simply queries an abstract user and detail
>part, not caring about how they are formed.

I guess my concern is that generalizing the wording will make it less
precise and more difficult to understand.  Currently there are some
fairly precise statements setting when :detail is or contains the empty
key; if this all becomes just a system-defined abstract query, how can
those requirements still be stated?


Philip Guenther

** As a footnote, VERP is _not_ an encoding but just the abstract idea
of using, well, Variable Envelope Return Paths.  The page that was
cited:
	http://cr.yp.to/proto/verp.txt
contains an example of a return-path that encodes an address, but it
does not actually provide anything like specification of an encoding.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24JUcDS005987; Sat, 4 Mar 2006 12:30:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k24JUcJr005986; Sat, 4 Mar 2006 12:30:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24JUbcp005979 for <[e-mail]>; Sat, 4 Mar 2006 12:30:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Sat, 4 Mar 2006 19:30:33 +0000
Message-ID: <[e-mail]>
Date: Sat, 04 Mar 2006 19:30:28 +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
To: MTA filtering mailing list <[e-mail]>
Subject: Tentative agenda for the Sieve WG meeting in Dallas
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 draft agenda for the Dallas IETF meeting:

Agenda

- Introduction (blue sheets, scribe etc) (1 min)
- Agenda Bashing (2 mins)
- Report on completed work (2 mins)
- Spamtest draft status (10 mins)
- Date draft status (5 mins)
- Subaddress draft status (5 mins)
- Regex draft status (5 mins)
- Reject/refuse draft (10 mins)
- MIME loops draft (20 mins)
- Notification draft (20 mins)
- Base spec status, in particular review of
  comparators (draft-newman-i18n-comparator-07.txt) and Sieve (10 mins)
- Other topics:
  Manage Sieve protocol (5 mins)
  Include draft (15 mins)
  Proposals for adding exception handling/optional require to Sieve (10 
mins)

Total: 120 minutes.
===============
The suggested order might look backward, but I would like to discuss 
easy documents first.

The items in the list I am not sure about: Regex (there is a new draft, 
but there was no progress done on I18N and I don't know if Ned is 
attending), MIME loops (how much time do we need for this one?), date 
(are there any open issues?).
Also, 10 minutes for discussing comparators is not enough, but as the 
comparator draft also affects IMAPEXT WG, there would be a longer 
discussion happening there.

Any comments?

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24HNtdA002019; Sat, 4 Mar 2006 10:23:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k24HNtZh002018; Sat, 4 Mar 2006 10:23:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24HNsHW002012 for <[e-mail]>; Sat, 4 Mar 2006 10:23:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Sat, 4 Mar 2006 17:23:36 +0000
Message-ID: <[e-mail]>
Date: Sat, 04 Mar 2006 00:00:19 +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: Agenda for Sieve WG meeting in Dallas
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 everyone,
Dallas meeting is approaching, so it is time to talk about agenda for 
Sieve WG meeting.
Can I please see a show of hands (off-list please) about who from 
editors is planning to attend and if a person is not attending, whom he 
wants to nominate as a presenter.
I would also appreciate a short message from each editor about status or 
their documents (recent changes, todo list, open issues).

Alexey

P.S. Both Cyrus and I are planning to attend the meeting.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24HNcKd002007; Sat, 4 Mar 2006 10:23:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k24HNcH9002006; Sat, 4 Mar 2006 10:23:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24HNaqV001998 for <[e-mail]>; Sat, 4 Mar 2006 10:23:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Sat, 4 Mar 2006 17:23:30 +0000
Message-ID: <[e-mail]>
Date: Fri, 03 Mar 2006 23:46:03 +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: Survey of spamtest implementations
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 folks,
I would like how many server or client implementations support spamtest 
extension as defined in RFC 3685. Please send replies directly to me.

Thanks,
Alexey




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24AufpE087963; Sat, 4 Mar 2006 03:56:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k24Aufnc087962; Sat, 4 Mar 2006 03:56:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24AudpQ087956 for <[e-mail]>; Sat, 4 Mar 2006 03:56:40 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FFURD-000107-4T for [e-mail]; Sat, 04 Mar 2006 11:56:39 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #60) id 1FFURD-0007Cg-1K for [e-mail]; Sat, 04 Mar 2006 11:56:39 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #1) id 1FFURA-0000aV-GU for [e-mail]; Sat, 04 Mar 2006 11:56:36 +0100
Date: Sat, 4 Mar 2006 11:56:36 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
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, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> My interpretation is that for that example address, the sieved handling
> mail for silverton.berkeley.edu would follow the qmail practice and
> split the localpart on the first '-', such that :user would specify
> 'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
> disagree or desire otherwise, please describe the additional (or
> alternative) processing you're looking for.

You misunderstand me.  The subaddress extension does not split addresses
on its own, but asks the underlying system to perform that operation,
and simply uses the results.  It does not specify if prefix or suffix
strings are to be used, but relies on the underlying system to know
the local convention:

   Note that
   the mechanisms used to define and/or query the separator character
   sequence and sub-part ordering used by the mail system are outside
   the scope of this document.

And things are good that way.

Unfortunately, it says: The only algorithm the underlying system may
perform is to use a separator for splitting the address in parts.

I ask to be less restrictive and allow the underlying system to split
the addresses in whatever way someone may want to configure it.

> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
> > used to decode it.  A filter in front of a MLM may be very useful.
> 
> You're looking for a means in sieved to extract the address
> <[e-mail]> from that address?  If so, what combination of
> keyword arguments would do that?  (What if _that_ address was a VERP?)

Yes.  Using :detail should be allowed to do that.  Let's not discuss
VERP, because as I said, it is a primitive encoding, but a great real
world example that shows substrings do not suffice.

> I didn't think VERPs were an all-or-nothing choice.  A user may send
> some messages with VERP-style address and others with random tags in the
> subaddress portion.  Please explain how a system that 'decoded' VERPs
> would support that.

Users usually do not send VERPs, but MLMs do.  The system that runs
the MLM would be configured to know which bounces belong to the MLM,
and set up subaddressing to decode VERP.  Mail that belongs to users
would be delivered with subaddressing set up as the local convention
for users is, i.e. <user+detail@domain>.

> VERPs are a optional encoding inside the subaddress encoding, ergo
> decoding of them should be separately performed or requested so that
> access to both levels can be provided.

If you want ultimate configurability, indeed variables and string
expressions are needed.  But all I ask for is making the subaddress
specification less restrictive on issues outsides its scope and change
it into an abstraction that simply queries an abstract user and detail
part, not caring about how they are formed.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23KOKxF060201; Fri, 3 Mar 2006 13:24:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k23KOKFb060200; Fri, 3 Mar 2006 13:24:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23KOJPg060194 for <[e-mail]>; Fri, 3 Mar 2006 13:24:20 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k23KOE4A020634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 3 Mar 2006 12:24:15 -0800
X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k23KOE4A020634
DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1141417456; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:From:Subject:In-reply-to:References:Date:Sender; b=c shrheEI7wP11x4RTJF/srJthGoVfPZLW1OAU7eCkVjPJM4q8oR7aUnq/yx70h4TCmIA O8DFJYbVjKPBhd4d/LvAOYVoC1LQdiWS3uqiUNm3h5sr/6GOPEiFJcXHMobp32pA8OA VGm0Kq/1F2UucI1euaaqzrYw8oXYjxIJgncM=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k23KOE4A020634
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:from:subject:in-reply-to: references:date:sender; b=TgsTy4y24JPmP7XY/VmvLS4J/qGjvs5/vek/qRoAXvhAhMC3BcmHb715N02t+HS1I ZArv1wSDWsQKkxCZ8ulwMJKECoa6YWGVweaxyguSxbQHNQZrGDIQQB7jVRicf9lw4FT s6bipGywx4lK/YYJFyoeuFF8s2Uh2r7JrdPuO7I=
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 k23KOE2O072767; Fri, 3 Mar 2006 12:24:14 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Fri, 03 Mar 2006 12:24:14 -0800
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]> writes:
...
>Quoting DJB:
>
>   Here is how VERPs work: each recipient of the message sees a
>   different envelope sender address. When a message to the
>   [e-mail] mailing list is sent to
>   [e-mail], for example, it has the following envelope sender:
>
>      djb-sos-owner-God=[e-mail]
>
>The "@" in the list member is replaced by "=".  A very primitive encoding,
>but an encoding, whereas the subaddress draft requires substrings.

My interpretation is that for that example address, the sieved handling
mail for silverton.berkeley.edu would follow the qmail practice and
split the localpart on the first '-', such that :user would specify
'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
disagree or desire otherwise, please describe the additional (or
alternative) processing you're looking for.

<from a previous message>
> Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> and if you relaxed the encoding specification, Sieve could be
> used to decode it.  A filter in front of a MLM may be very useful.

You're looking for a means in sieved to extract the address
<[e-mail]> from that address?  If so, what combination of
keyword arguments would do that?  (What if _that_ address was a VERP?)

Note that you can already extract that address using variables.  Doing
so requires knowledge of what prefixes should be stripped ala
"sos-owner-" in this case.  And no, you can't strip on the last '-'
before the '=' as the wrapped address may have a '-' in its localpart.


>To me, a subaddress is additional information encoded in the address.
>We already recognized that in general, subaddress decoding can only
>be done by receiving system for its own addresses.  If that involves
>splitting strings, translating characters or performing cryptographic
>operations, should not be of any concern to the extension that allows
>access to the decoded user and detail part.

I didn't think VERPs were an all-or-nothing choice.  A user may send
some messages with VERP-style address and others with random tags in the
subaddress portion.  Please explain how a system that 'decoded' VERPs
would support that.

VERPs are a optional encoding inside the subaddress encoding, ergo
decoding of them should be separately performed or requested so that
access to both levels can be provided.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23JHKXC058510; Fri, 3 Mar 2006 12:17:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k23JHKTk058509; Fri, 3 Mar 2006 12:17:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23JHJeg058503 for <[e-mail]>; Fri, 3 Mar 2006 12:17:19 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FFFmA-0004PJ-Pc for [e-mail]; Fri, 03 Mar 2006 20:17:18 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #60) id 1FFFmA-0001SP-NR for [e-mail]; Fri, 03 Mar 2006 20:17:18 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #1) id 1FFFmA-0000QE-De for [e-mail]; Fri, 03 Mar 2006 20:17:18 +0100
Date: Fri, 3 Mar 2006 20:17:18 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
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, Mar 03, 2006 at 09:03:05AM -0800, Ned Freed wrote:
> > This draft allows both prefix and suffix encoding, but still requires
> > both user and detail part to be substrings of the local part.
> 
> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
> > used to decode it.  A filter in front of a MLM may be very useful.
> 
> I fail to see the mismatch. In a VERP scheme the user part tells you the name
> of the list whie the detail part tells you the address that failed.

Quoting DJB:

   Here is how VERPs work: each recipient of the message sees a
   different envelope sender address. When a message to the
   [e-mail] mailing list is sent to
   [e-mail], for example, it has the following envelope sender:

      djb-sos-owner-God=[e-mail]

The "@" in the list member is replaced by "=".  A very primitive encoding,
but an encoding, whereas the subaddress draft requires substrings.

To me, a subaddress is additional information encoded in the address.
We already recognized that in general, subaddress decoding can only
be done by receiving system for its own addresses.  If that involves
splitting strings, translating characters or performing cryptographic
operations, should not be of any concern to the extension that allows
access to the decoded user and detail part.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23H7g2M053681; Fri, 3 Mar 2006 10:07:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k23H7g2b053680; Fri, 3 Mar 2006 10:07:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([209.55.107.55]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23H7fOp053674 for <[e-mail]>; Fri, 3 Mar 2006 10:07:41 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 3 Mar 2006 09:07:39 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1141405659; h=Date: 	 From:Subject:MIME-version:Content-type; b=WqBrsk2FWTQawi2JO1kg9cNA9 pco8E3T7YAxSkmJ8ajfc4PQEFRp26gG60LSg10XjotGYQbhNqOYIgkY8X9ATA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 03 Mar 2006 09:07:37 -0800 (PST)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 03 Mar 2006 09:03:05 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
In-reply-to: "Your message dated Fri, 03 Mar 2006 15:14:39 +0100" <[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 Fri, Feb 17, 2006 at 03:50:01PM -0500, [e-mail] wrote:
> > 	Title		: Sieve Email Filtering -- Subaddress Extension
> > 	Author(s)	: K. Murchison
> > 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> > 	Pages		: 14
> > 	Date		: 2006-2-17

> This draft allows both prefix and suffix encoding, but still requires
> both user and detail part to be substrings of the local part.

> Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> and if you relaxed the encoding specification, Sieve could be
> used to decode it.  A filter in front of a MLM may be very useful.

I fail to see the mismatch. In a VERP scheme the user part tells you the name
of the list whie the detail part tells you the address that failed.

I suppose you could also use subdomains to encode some of this information
(VERP is an approach, not a particular encoding), but that's not how it is
normally done.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23EEfgS046643; Fri, 3 Mar 2006 07:14:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k23EEf9d046642; Fri, 3 Mar 2006 07:14:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23EEe8D046634 for <[e-mail]>; Fri, 3 Mar 2006 07:14:41 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1FFB3H-0000Su-DZ for [e-mail]; Fri, 03 Mar 2006 15:14:39 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #60) id 1FFB3H-00023t-CL for [e-mail]; Fri, 03 Mar 2006 15:14:39 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #1) id 1FFB3H-0000Cv-2M for [e-mail]; Fri, 03 Mar 2006 15:14:39 +0100
Date: Fri, 3 Mar 2006 15:14:39 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.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>

On Fri, Feb 17, 2006 at 03:50:01PM -0500, [e-mail] wrote:
> 	Title		: Sieve Email Filtering -- Subaddress Extension
> 	Author(s)	: K. Murchison
> 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> 	Pages		: 14
> 	Date		: 2006-2-17

This draft allows both prefix and suffix encoding, but still requires
both user and detail part to be substrings of the local part.

Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
and if you relaxed the encoding specification, Sieve could be
used to decode it.  A filter in front of a MLM may be very useful.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22KoArc009796; Thu, 2 Mar 2006 13:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22KoA3p009794; Thu, 2 Mar 2006 13:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22KoAWZ009783 for <[e-mail]>; Thu, 2 Mar 2006 13:50:10 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko10e023355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukL-0003P0-PX; Thu, 02 Mar 2006 15:50:01 -0500
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-mime-loop-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 02 Mar 2006 15:50:01 -0500
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 Extensions:  MIME Tests, MIME Bodypart Iteration, Replacement and Enclosure
	Author(s)	: T. Hansen, C. Daboo
	Filename	: draft-ietf-sieve-mime-loop-00.txt
	Pages		: 9
	Date		: 2006-3-2
	
   The current Sieve language has no way to look at individual MIME
   parts, looping mechanism, or any way to manipulate those individual
   parts.  This document defines extensions for each of these needs.

   This document is being discussed in the MTA-FILTERS mailing lists,
   [e-mail].



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-00.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-mime-loop-00.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-mime-loop-00.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-mime-loop-00.txt

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

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

--OtherAccess--

--NextPart--