Re: NULL vs. ""

[Ned Freed <[e-mail]>]

> On Tue, 2005-05-31 at 07:21 -0400, Mark E. Mallett wrote:
> > I think a NULL test of some sort could be useful with variables,
> > but that's another road that's already been paved...

> not sure what that expression means, but the document hasn't been
> approved yet, so changes can still happen.

The variables draft has been in process for over two years now. It's time to
wrap it up and get it out the door.

> the test introduced with variables is "string", so there is no way to
> access the value of a variable except inside a string.  likewise for
> setting a variable, you (currently) have to provide a string.  having
> "${unset_variable}" extrapolate to a special value rather than a string
> is IMO ugly and counter-intuitive.

> to support NULL values with variables, I see two alternatives:

>         a) a new test which takes a variable _name_ as its argument.  we
>         also need a NULL token which can be used with that test and with
>         SET.
        
>         b) a new test to check explicitly for unset values.  a new
>         action UNSET which can only set variables to the NULL value.

> I don't really like a NULL/UNSET token, it opens to many issues.  I
> wouldn't mind adding alternative b) to the spec, though, it may be
> useful in some cases.

Exactly what urgently-need funcitonality does any of this provide? I sure
don't see any.

				Ned

P.S. Yes, I realize the vacation draft is even more overdue. I plan to send out
one more revision and then ask for WGLC in the next week. It would be good
if variables could join it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VFUDCn092255; Tue, 31 May 2005 08:30:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VFUD57092254; Tue, 31 May 2005 08:30:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VFUCRf092247 for <[e-mail]>; Tue, 31 May 2005 08:30:12 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 31 May 2005 08:30:08 -0700 (PDT)
Cc: Mark E Mallett <[e-mail]>, [e-mail]
Date: Tue, 31 May 2005 08:23:33 -0700 (PDT)
From: Ned Freed <[e-mail]>
In-reply-to: "Your message dated Tue, 31 May 2005 15:57:21 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: NULL vs. ""
To: Kjetil Torgrim Homme <[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 Tue, 2005-05-31 at 07:21 -0400, Mark E. Mallett wrote:
> > I think a NULL test of some sort could be useful with variables,
> > but that's another road that's already been paved...

> not sure what that expression means, but the document hasn't been
> approved yet, so changes can still happen.

The variables draft has been in process for over two years now. It's time to
wrap it up and get it out the door.

> the test introduced with variables is "string", so there is no way to
> access the value of a variable except inside a string.  likewise for
> setting a variable, you (currently) have to provide a string.  having
> "${unset_variable}" extrapolate to a special value rather than a string
> is IMO ugly and counter-intuitive.

> to support NULL values with variables, I see two alternatives:

>         a) a new test which takes a variable _name_ as its argument.  we
>         also need a NULL token which can be used with that test and with
>         SET.
        
>         b) a new test to check explicitly for unset values.  a new
>         action UNSET which can only set variables to the NULL value.

> I don't really like a NULL/UNSET token, it opens to many issues.  I
> wouldn't mind adding alternative b) to the spec, though, it may be
> useful in some cases.

Exactly what urgently-need funcitonality does any of this provide? I sure
don't see any.

				Ned

P.S. Yes, I realize the vacation draft is even more overdue. I plan to send out
one more revision and then ask for WGLC in the next week. It would be good
if variables could join it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEWipg087893; Tue, 31 May 2005 07:32:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VEWiHW087892; Tue, 31 May 2005 07:32:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4VEWhP9087886 for <[e-mail]>; Tue, 31 May 2005 07:32:43 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 88121 invoked by uid 101); 31 May 2005 10:32:42 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 31 May 2005 10:32:42 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: NULL vs. ""
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[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, May 31, 2005 at 03:57:21PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2005-05-31 at 07:21 -0400, Mark E. Mallett wrote:
> > I think a NULL test of some sort could be useful with variables,
> > but that's another road that's already been paved...
> 
> not sure what that expression means, but the document hasn't been
> approved yet, so changes can still happen.

Nothing sinister..  just an acknowledgement that people would like to
get on with finalizing that draft and not enter into new tangents in it.


> the test introduced with variables is "string", so there is no way to
> access the value of a variable except inside a string.  likewise for
> setting a variable, you (currently) have to provide a string.  having
> "${unset_variable}" extrapolate to a special value rather than a string
> is IMO ugly and counter-intuitive.

Probably so.  There could conceivably be different kinds of syntaxes to
do different kinds of expansions, though; I think that notion has been
raised before.  e.g. one could borrow from 'sh' syntax, which has:

    ${var:alt}

where the text "alt" is used if 'var' does not exist as a variable.
Or some other kind of expansion controls, e.g. other tagged options
in "set" (along the lines of :length).  



> to support NULL values with variables, I see two alternatives:
> 
>         a) a new test which takes a variable _name_ as its argument.  we
>         also need a NULL token which can be used with that test and with
>         SET.
>         
>         b) a new test to check explicitly for unset values.  a new
>         action UNSET which can only set variables to the NULL value.
> 
> I don't really like a NULL/UNSET token, it opens to many issues.  I
> wouldn't mind adding alternative b) to the spec, though, it may be
> useful in some cases.

Seems rational to me, but then again there's that thing about delaying
the draft with more reviews.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEIosB086361; Tue, 31 May 2005 07:18:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VEIoFU086360; Tue, 31 May 2005 07:18:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4VEInYb086353 for <[e-mail]>; Tue, 31 May 2005 07:18:50 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id A038C1A754; Tue, 31 May 2005 16:18:47 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 2AD0F1A6BD; Tue, 31 May 2005 16:18:41 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 31 May 2005 16:16:42 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: NULL vs. ""
Cc: "Mark E. Mallett" <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[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>

Kjetil Torgrim Homme writes:
> I wouldn't mind adding alternative b) to the spec, though, it may be 
> useful in some cases.

I'd say no. Noone has asked for it yet.

Nigel needed something to do with emptiness or nullness, but I didn't 
really understand what. Doesn't seem as though he wanted b), though.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDvfGt084428; Tue, 31 May 2005 06:57:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDvfPn084427; Tue, 31 May 2005 06:57:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDveNw084417 for <[e-mail]>; Tue, 31 May 2005 06:57:40 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1Dd7FQ-000649-8C; Tue, 31 May 2005 15:57:36 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Dd7FI-0004Ki-RC; Tue, 31 May 2005 15:57:28 +0200
Subject: Re: NULL vs. ""
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 31 May 2005 15:57:21 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.134, required 12, autolearn=disabled, AWL 1.82, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-05-31 at 07:21 -0400, Mark E. Mallett wrote:
> I think a NULL test of some sort could be useful with variables,
> but that's another road that's already been paved...

not sure what that expression means, but the document hasn't been
approved yet, so changes can still happen.

the test introduced with variables is "string", so there is no way to
access the value of a variable except inside a string.  likewise for
setting a variable, you (currently) have to provide a string.  having
"${unset_variable}" extrapolate to a special value rather than a string
is IMO ugly and counter-intuitive.

to support NULL values with variables, I see two alternatives:

        a) a new test which takes a variable _name_ as its argument.  we
        also need a NULL token which can be used with that test and with
        SET.
        
        b) a new test to check explicitly for unset values.  a new
        action UNSET which can only set variables to the NULL value.

I don't really like a NULL/UNSET token, it opens to many issues.  I
wouldn't mind adding alternative b) to the spec, though, it may be
useful in some cases.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VBLGPo043268; Tue, 31 May 2005 04:21:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VBLGOs043267; Tue, 31 May 2005 04:21:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4VBLELn043248 for <[e-mail]>; Tue, 31 May 2005 04:21:14 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 38004 invoked by uid 101); 31 May 2005 07:21:13 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 31 May 2005 07:21:13 -0400
To: Nigel Swinson <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: NULL vs. ""
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <008201c5651b$ef375370$[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, May 30, 2005 at 02:31:47PM +0100, Nigel Swinson wrote:

> if anyof (header :is "Cc" "", not exists "Cc")

Given that the language definition has no way to express a NULL, I don't
see that as a bad way to state the test.  It's clearer to me than the
regex solution (and the equivalent :matches solution).

Even if there was a way to express a NULL, the following:

> What might be nice is if we could say:
> 
> if header :is "Cc" NULL  // ie if the header is absent or empty

really wouldn't work either.  A NULL would still have to be different
from the empty string, so you'd have to say:

    if header :is "Cc" [ NULL, "" ]  // if the header is absent or empty

which is indeed slightly tighter and clearer than the 'anyof' test.
Personally I'm not against having a NULL reserved keyword that
represents a missing string value, but it would probably involve a lot
of changes to existing implementations.  I doubt it would be disruptive
to existing sieve scripts though-- only to implementations, thus it
would have to be done via an extension and not a 3028bis addition, and
probably would be quite a bit of an uphill battle.

I think a NULL test of some sort could be useful with variables,
but that's another road that's already been paved...

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UHMnn4047842; Mon, 30 May 2005 10:22:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UHMnvD047841; Mon, 30 May 2005 10:22:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UHMmr9047833 for <[e-mail]>; Mon, 30 May 2005 10:22:48 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 30 May 2005 10:22:45 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Date: Mon, 30 May 2005 10:17:27 -0700 (PDT)
From: Ned Freed <[e-mail]>
In-reply-to: "Your message dated Mon, 30 May 2005 18:55:47 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: NULL vs. ""
To: Kjetil Torgrim Homme <[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, 2005-05-30 at 09:21 -0700, Ned Freed wrote:
> > > if anyof (header :is "Cc" "", not exists "Cc")
> >
> > This is actually clearer to read IMO, and is probably how I would code it if
> > I ever wanted such a test.

> the alternative would be to redefine the semantics of header :is so that
> header :is "Cc" "" is true even when Cc is non-existent.  those who
> wishes to check for existance still have the exists test.  this shifts
> the need for "awkward" code over to those who write careful code in the
> first place.

it is much too late to make such a change without it being a new capability.

> I'm not sure if such a change to Sieve can be made without the script
> explicitly asking for it.  it seems pretty innocuous to me, but the
> gains are pretty slim, too.

One way you complicate the test for an empty field. The other way you
complicate the test for a missing-or-empty field. The use cases for either one
are not particularly compelling, and given the large cost associated with each
new capability, leaving things alone is the obvious right answer.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGu1hG046112; Mon, 30 May 2005 09:56:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGu13E046111; Mon, 30 May 2005 09:56:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGu0c9046101 for <[e-mail]>; Mon, 30 May 2005 09:56:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DcnYS-0005Bn-QC; Mon, 30 May 2005 18:55:56 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DcnYP-00021L-P3; Mon, 30 May 2005 18:55:53 +0200
Subject: Re: NULL vs. ""
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]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 30 May 2005 18:55:47 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.091, required 12, autolearn=disabled, AWL 1.86, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-05-30 at 09:21 -0700, Ned Freed wrote:
> > if anyof (header :is "Cc" "", not exists "Cc")
> 
> This is actually clearer to read IMO, and is probably how I would code it if
> I ever wanted such a test.

the alternative would be to redefine the semantics of header :is so that
header :is "Cc" "" is true even when Cc is non-existent.  those who
wishes to check for existance still have the exists test.  this shifts
the need for "awkward" code over to those who write careful code in the
first place.

I'm not sure if such a change to Sieve can be made without the script
explicitly asking for it.  it seems pretty innocuous to me, but the
gains are pretty slim, too.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGn2Ck045688; Mon, 30 May 2005 09:49:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGn23i045687; Mon, 30 May 2005 09:49:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGn1Vu045681 for <[e-mail]>; Mon, 30 May 2005 09:49:01 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed; charset=iso-8859-1; reply-type=original
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 30 May 2005 09:49:00 -0700 (PDT)
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Date: Mon, 30 May 2005 09:29:50 -0700 (PDT)
From: Ned Freed <[e-mail]>
In-reply-to: "Your message dated Mon, 30 May 2005 17:10:18 +0100" <016001c56532$14a4c500$[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]> <016001c56532$14a4c500$[e-mail]>
Subject: Re: NULL vs. ""
To: Nigel Swinson <[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>

> >> The discussion reminds me of when I was trying to write gui to say "when
> >> header X is empty" [...] I eventually ended up with:
> >>
> >> if not header :regex "Cc" "."    // If there is no Cc header that
> >> contains
> >> any character
> >>
> >> Which felt pretty clumsy for what seems to be a pretty obvious use for
> >> Sieve.
> >
> > can you expound a little on this obvious use?  I don't see the use case,
> > myself, and am therefore skeptical to the need for a new reserved word
> > NULL.

> Well the user is trying to say "where there is no information in XXXX
> headers".

Careful here. The simple presence of a field can be used to convey information.
Bcc: is the obvious example - now that recipient fields are optional it can be
used to indicate bcc copies were sent. RFC 2822 calls out this usage
specifically, as a matter of fact. I'm not sure I would ever write
a script that tested bcc this way, however, given how many transport
agents summarily (and incorrectly) drop bcc fields from messages in transport.

I have also seen an empty keywords field used to indicate "we checked for
applicable keywords but didn't find any", although RFC 2822 appears to disallow
this usage.

> They don't care if the the header is absent, or is empty, they
> just care that it contains no data and want to switch on both in the same
> manner.  So I could imagine script wanting to say:

> "If there are no Cc addresses"
> "If there is no subject"
> "If there is no spam score header"
> "If there is no virus score header information"
> "If the priority of the message is not specified"

> Headers with no value to them sound pretty useless,

Not necessarily. See above.

> but of course some
> headers are required to be there to meet the standards, and a header with no
> value isn't prohibted by the standards, so a sensible filter really should
> accommodate them.  It feels as though sieve as it stands leaves the user to
> write a couple of faulty scripts before they finally write their anyof(not
> exists, is empty) test.

I'm again failing to see the real use case. Of course you can write users want
this or that behavior, but wanting something doesn't mean it is actually
useful. About the closest thing here is the "no subject" test you cite - I
could sort of see wanting to treat an empty subject the same way as as no
subject. Recipient field tests that go beyond things testing for explicit
presence of a particular address have always struck me as extremely risky given
the vagarities of how clients construct these fields and how they get mangled
by the transport infrastructure. As for score tests, this is probably a case
where you want to distinguish between no field and an invalid field (an empty
field is presumably invalid).

> Of course this issue can be abstracted away and solved in the gui, I just
> thought it was an issue worth bringing up in the context of this NULL/""
> discussion, and wondered if it was worth us providing an easier solution for
> writing these filters.

IMO the proposed solution adds complexity without adding value.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGSxRx044509; Mon, 30 May 2005 09:28:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGSxuN044508; Mon, 30 May 2005 09:28:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGSw7S044501 for <[e-mail]>; Mon, 30 May 2005 09:28:58 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed; charset=UTF-8; reply-type=response
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 30 May 2005 09:28:56 -0700 (PDT)
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Date: Mon, 30 May 2005 09:21:27 -0700 (PDT)
From: Ned Freed <[e-mail]>
In-reply-to: "Your message dated Mon, 30 May 2005 14:31:47 +0100" <008201c5651b$ef375370$[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]>
Subject: Re: NULL vs. ""
To: Nigel Swinson <[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>

> > I'm not sure what a NULL string means in the context of Sieve, 822, or at
> > all, actually.

> I suppose we are saying it's the value of an absent header, not just an
> empty header.

> The discussion reminds me of when I was trying to write gui to say "when
> header X is empty" and then was surprised how many iterations of script I
> went through until I got exactly what I wanted.  These were both wrong in
> terms of the concept I was trying to communicate to users:

> if header :is "Cc" ""  // ie if there is a header that is blank
> if not exists "Cc"        // ie if the header does not exist

> I eventually ended up with:

> if not header :regex "Cc" "."    // If there is no Cc header that contains
> any character

> Which felt pretty clumsy for what seems to be a pretty obvious use for
> Sieve.  It also requires regex, which isn't necesarily available.

Regex isn't necessary here. While I fail to see a use case for this particular
test, the first way to code this as a single test that came to mind was:

  if not header :matches "Cc" "*?*

Seems very straightforward to me.

> Thealternative being:

> if anyof (header :is "Cc" "", not exists "Cc")

This is actually clearer to read IMO, and is probably how I would code it if
I ever wanted such a test.

> But a NULL string concept doesn't really help much here either, as it
> basically offers the same as what we have with the exists test, but it just
> allows you do use variables instead of the exists test directly.  Perhaps
> most of the time you would actually want to treat absent headers the same as
> empty headers in terms of processing, and if you really wanted to make the
> distinction then you could just use exists?

> What might be nice is if we could say:

> if header :is "Cc" NULL  // ie if the header is absent or empty

The semantics of this are not at all obvious from inspection. Given that it is
both unnecessary and IMO much less readable, I see no justificatio for adding
it and lots of justification for keeping it out.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGASgK043489; Mon, 30 May 2005 09:10:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGAS7r043487; Mon, 30 May 2005 09:10:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGARDr043469 for <[e-mail]>; Mon, 30 May 2005 09:10:27 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.20) with ESMTP id <[e-mail]>; Mon, 30 May 2005 09:10:22 -0700
Message-ID: <016001c56532$14a4c500$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]> <[e-mail]>
Subject: Re: NULL vs. ""
Date: Mon, 30 May 2005 17:10:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> The discussion reminds me of when I was trying to write gui to say "when
>> header X is empty" [...] I eventually ended up with:
>>
>> if not header :regex "Cc" "."    // If there is no Cc header that 
>> contains
>> any character
>>
>> Which felt pretty clumsy for what seems to be a pretty obvious use for
>> Sieve.
>
> can you expound a little on this obvious use?  I don't see the use case,
> myself, and am therefore skeptical to the need for a new reserved word
> NULL.

Well the user is trying to say "where there is no information in XXXX 
headers".  They don't care if the the header is absent, or is empty, they 
just care that it contains no data and want to switch on both in the same 
manner.  So I could imagine script wanting to say:

"If there are no Cc addresses"
"If there is no subject"
"If there is no spam score header"
"If there is no virus score header information"
"If the priority of the message is not specified"

Headers with no value to them sound pretty useless, but of course some 
headers are required to be there to meet the standards, and a header with no 
value isn't prohibted by the standards, so a sensible filter really should 
accommodate them.  It feels as though sieve as it stands leaves the user to 
write a couple of faulty scripts before they finally write their anyof(not 
exists, is empty) test.

Of course this issue can be abstracted away and solved in the gui, I just 
thought it was an issue worth bringing up in the context of this NULL/"" 
discussion, and wondered if it was worth us providing an easier solution for 
writing these filters.

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UFgbp7041770; Mon, 30 May 2005 08:42:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UFgbR1041769; Mon, 30 May 2005 08:42:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UFgajv041760 for <[e-mail]>; Mon, 30 May 2005 08:42:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DcmPQ-0002zB-Sc; Mon, 30 May 2005 17:42:32 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DcmPO-0004uO-BR; Mon, 30 May 2005 17:42:30 +0200
Subject: Re: NULL vs. ""
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <008201c5651b$ef375370$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008201c5651b$ef375370$[e-mail]>
Content-Type: text/plain
Date: Mon, 30 May 2005 17:42:24 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.126, required 12, autolearn=disabled, AWL 1.82, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-05-30 at 14:31 +0100, Nigel Swinson wrote:
> The discussion reminds me of when I was trying to write gui to say "when 
> header X is empty" [...] I eventually ended up with:
> 
> if not header :regex "Cc" "."    // If there is no Cc header that contains 
> any character
> 
> Which felt pretty clumsy for what seems to be a pretty obvious use for 
> Sieve.

can you expound a little on this obvious use?  I don't see the use case,
myself, and am therefore skeptical to the need for a new reserved word
NULL.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UDW1u6029105; Mon, 30 May 2005 06:32:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UDW1de029104; Mon, 30 May 2005 06:32:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UDW0of029087 for <[e-mail]>; Mon, 30 May 2005 06:32:00 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.20) with ESMTP id <[e-mail]>; Mon, 30 May 2005 06:31:50 -0700
Message-ID: <008201c5651b$ef375370$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Cc: "Arnt Gulbrandsen" <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <+z3UjvPElTb9bVSsE4a/[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: NULL vs. ""
Date: Mon, 30 May 2005 14:31:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I'm not sure what a NULL string means in the context of Sieve, 822, or at 
> all, actually.

I suppose we are saying it's the value of an absent header, not just an 
empty header.

The discussion reminds me of when I was trying to write gui to say "when 
header X is empty" and then was surprised how many iterations of script I 
went through until I got exactly what I wanted.  These were both wrong in 
terms of the concept I was trying to communicate to users:

if header :is "Cc" ""  // ie if there is a header that is blank
if not exists "Cc"        // ie if the header does not exist

I eventually ended up with:

if not header :regex "Cc" "."    // If there is no Cc header that contains 
any character

Which felt pretty clumsy for what seems to be a pretty obvious use for 
Sieve.  It also requires regex, which isn't necesarily available.  The 
alternative being:

if anyof (header :is "Cc" "", not exists "Cc")

But a NULL string concept doesn't really help much here either, as it 
basically offers the same as what we have with the exists test, but it just 
allows you do use variables instead of the exists test directly.  Perhaps 
most of the time you would actually want to treat absent headers the same as 
empty headers in terms of processing, and if you really wanted to make the 
distinction then you could just use exists?

What might be nice is if we could say:

if header :is "Cc" NULL  // ie if the header is absent or empty

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RKZMFW043698; Fri, 27 May 2005 13:35:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RKZM1u043697; Fri, 27 May 2005 13:35:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RKZLJp043691 for <[e-mail]>; Fri, 27 May 2005 13:35:22 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 27 May 2005 13:35:20 -0700 (PDT)
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Date: Fri, 27 May 2005 13:34:51 -0700 (PDT)
From: Ned Freed <[e-mail]>
In-reply-to: "Your message dated Fri, 27 May 2005 13:02:01 -0700" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: NULL vs. ""
To: Tim Showalter <[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>

> Arnt Gulbrandsen wrote:
> >
> > And since "" is a empty string, not an NULL string. The comparator text
> > states that NULL strings aren't substrings of anything, so :contains
> > ["X-Caffeine"] [:null] should evaluate to false (if :null were valid).

> I deeply regret using the words "null string" and apologize for my
> ignorance.

> "null" should be changed to "empty" everywhere in 3028bis, and we can
> avoid this confusion.

> I'm not sure what a NULL string means in the context of Sieve, 822, or
> at all, actually.

It's nice to know I'm not the only one who is confused by all this.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RK32jc038126; Fri, 27 May 2005 13:03:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RK32Gk038125; Fri, 27 May 2005 13:03:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RK30Uv038097 for <[e-mail]>; Fri, 27 May 2005 13:03:00 -0700 (PDT) (envelope-from [e-mail])
Received: from [66.228.163.20] (trustwho.corp.yahoo.com [66.228.163.20]) by mrout2.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4RK21tQ096484; Fri, 27 May 2005 13:02:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 27 May 2005 13:02:01 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050215)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: NULL vs. ""
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <+z3UjvPElTb9bVSsE4a/[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; 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>

Arnt Gulbrandsen wrote:
> 
> And since "" is a empty string, not an NULL string. The comparator text 
> states that NULL strings aren't substrings of anything, so :contains 
> ["X-Caffeine"] [:null] should evaluate to false (if :null were valid).

I deeply regret using the words "null string" and apologize for my 
ignorance.

"null" should be changed to "empty" everywhere in 3028bis, and we can 
avoid this confusion.

I'm not sure what a NULL string means in the context of Sieve, 822, or 
at all, actually.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RJXDRZ032521; Fri, 27 May 2005 12:33:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RJXDvl032520; Fri, 27 May 2005 12:33:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RJXCVv032511 for <[e-mail]>; Fri, 27 May 2005 12:33:12 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4RJWnb3024413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 27 May 2005 12:32:50 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j4RJWnb3024413
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=DabVex0fohKlIky5n7xl+Oxb3ntlxe/Bx//SzJlOJfC1AGpMlxFZPTV2Sp4cYkasQ 81BxvazBVUFyCaILQJYK43++QhAhDK6hgVyWDKqRp3puS91Ule2xjr12LAAHzmFaJN1 MVJcUu4XunBKiLLEToFgSo7PcnD9VgcVoFa5W7U=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j4RJWksI028007; Fri, 27 May 2005 12:32:49 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>
Subject: Re: NULL vs. "" 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Fri, 27 May 2005 12:32:46 -0700
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>

Arnt Gulbrandsen <[e-mail]> writes:
>
>Kjetil Torgrim Homme writes:
>> On Fri, 2005-05-27 at 14:49 +0200, Arnt Gulbrandsen wrote:
>>>  >            header :is ["X-Caffeine"] [""]         => false
>>>  >            header :contains ["X-Caffeine"] [""]   => true
>>>
>>>  There are no null strings here, only empty strings, so I don't think 
>>>  it's relevant.
>>
>> the example wasn't very relevant here, since the header exists.
>
>And since "" is a empty string, not an NULL string. The comparator text 
>states that NULL strings aren't substrings of anything, so :contains 
>["X-Caffeine"] [:null] should evaluate to false (if :null were valid).

Right.  To avoid confusion going forward, I've updated the base-spec to
refer to the zero-length string ("") as "empty" instead of "null".

Hmm, perhaps the third text paragraph of section 5.7 ("Test Header")
should say that if a named header is not present, then its value is the
NULL string (...with verbiage to keep people from confusing that with
the empty string).  Indeed, the behavior of matches against missing
headers could be construed as underspecified currently.  Sure, a missing
header doesn't contain the empty string, but does is compare equal to
zero under the i;ascii-numeric comparator?


>Well, can you show some example where it actually makes a difference, 
>and where the difference is useful? It has to be some collation 
>operation where it's sensible and understandable that NULL (TBD) is 
>distinct from "". The draft offers two properties that seem relevant to 
>sieve:
>
>1. NULL is equal only to NULL. The example could use :is.
>
>2. NULL is not a substring of anything. The example could rely on 
>:contains to return false if the second argument is NULL.

Neither of these can be expressed in sieve, as sieve has no way to
express a NULL second argument to a comparison.  The reverse of the
first of those ("NULL !:is non-NULL") is arguably used when the header
test is given a header name that isn't present.

(I can also imagine an implementation that treated
	address :domain "To" "example.com"
as using a NULL string for the domain when the address in the To field
was syntactically invalid by lack of a domain part, ala:
	To: John Smith <smith>
...but how invalid inputs are handled is beyond the scope of the spec.)


>I can't construct such an example, and I really don't want to take the 
>draft forward with a feature that's incompatible with some running code 
>and whose utility I cannot explain.

The alternative is for every application that uses collations and
combines the comparison with a key lookup (i.e., anything that rolls an
email header value lookup into the operation) to describe how the "key
not found" case is handled.  The -03 rev of the collation registry draft
let both application protocols and collations override the default
handling of NULL strings; dropping them would effectively make that
_just_ application specified.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RET83E072986; Fri, 27 May 2005 07:29:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RET8PM072985; Fri, 27 May 2005 07:29:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4RET7iF072979 for <[e-mail]>; Fri, 27 May 2005 07:29:08 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 398741A6E7; Fri, 27 May 2005 16:29:05 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id DF4821A6C1; Fri, 27 May 2005 16:28:58 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 27 May 2005 16:28:11 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: NULL vs. ""
Cc: Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[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>

Kjetil Torgrim Homme writes:
> On Fri, 2005-05-27 at 14:49 +0200, Arnt Gulbrandsen wrote:
>>  >            header :is ["X-Caffeine"] [""]         => false
>>  >            header :contains ["X-Caffeine"] [""]   => true
>>
>>  There are no null strings here, only empty strings, so I don't think 
>>  it's relevant.
>
> the example wasn't very relevant here, since the header exists.

And since "" is a empty string, not an NULL string. The comparator text 
states that NULL strings aren't substrings of anything, so :contains 
["X-Caffeine"] [:null] should evaluate to false (if :null were valid).

> consider instead:
>
>    header :contains "X-Absent" ""
>
> the LHS of the comparison is the value of lookup_header("X-Absent"), 
> and it returns a NULL value (do not confuse with "null key" :-).  it 
> seems to me that the comparator draft needs to support NULL values to 
> be able to support Sieve semantics.

Well, can you show some example where it actually makes a difference, 
and where the difference is useful? It has to be some collation 
operation where it's sensible and understandable that NULL (TBD) is 
distinct from "". The draft offers two properties that seem relevant to 
sieve:

1. NULL is equal only to NULL. The example could use :is.

2. NULL is not a substring of anything. The example could rely on 
:contains to return false if the second argument is NULL.

I can't construct such an example, and I really don't want to take the 
draft forward with a feature that's incompatible with some running code 
and whose utility I cannot explain.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RE5tci071495; Fri, 27 May 2005 07:05:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RE5tJv071494; Fri, 27 May 2005 07:05:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RE5sDa071477 for <[e-mail]>; Fri, 27 May 2005 07:05:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1DbfTB-0005pi-RE; Fri, 27 May 2005 16:05:50 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DbfT8-0001Uy-Mh; Fri, 27 May 2005 16:05:46 +0200
Subject: Re: NULL vs. ""
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <+z3UjvPElTb9bVSsE4a/[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <+z3UjvPElTb9bVSsE4a/[e-mail]>
Content-Type: text/plain
Date: Fri, 27 May 2005 16:05:40 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.125, required 12, autolearn=disabled, AWL 1.82, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-05-27 at 14:49 +0200, Arnt Gulbrandsen wrote:
> If you'll look at draft-newman-comparator (currently expired) you'll see 
> that "NULL strings" are mentioned in section 4.6, the behaviour of 
> comparing, equality testing and substring testing on NULL strings is 
> defined, but a NULL string itself is defined only implicitly as "a 
> string that contains no characters and is not the same as an empty 
> string".

aha, thanks for the pointer for where you're coming from.

> In the context of sieve, that would seem to encompass the value of an 
> absent header field, the value of a variable that is initialized from 
> such a header field, etc.

yes.

> > are you proposing to change the semantics of the header test?
> 
> I think I'm not.
> 
> I agree it's not generally true, but I'm not sure whether it's completely true.
> 
> I want to either kill NULL strings in the comparator draft or provide a 
> raison d'etre in the form of a good example. Either is fine with me. 
> And I want to be compatible with the established use of comparators.
> 
> >    If a header listed in the header-names argument exists, it contains 
> >    the null key ("").  However, if the named header is not present, 
> >    it does not contain the null key.  So if a message contained the 
> >    header
> >
> >            X-Caffeine: C8H10N4O2
> >
> >    these tests on that header evaluate as follows:
> >
> >            header :is ["X-Caffeine"] [""]         => false
> >            header :contains ["X-Caffeine"] [""]   => true
> 
> There are no null strings here, only empty strings, so I don't think 
> it's relevant.

the example wasn't very relevant here, since the header exists.
consider instead:

   header :contains "X-Absent" ""

the LHS of the comparison is the value of lookup_header("X-Absent"), and
it returns a NULL value (do not confuse with "null key" :-).  it seems
to me that the comparator draft needs to support NULL values to be able
to support Sieve semantics.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCohA8057830; Fri, 27 May 2005 05:50:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCohh8057828; Fri, 27 May 2005 05:50:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4RCogKX057816 for <[e-mail]>; Fri, 27 May 2005 05:50:43 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id DB8161A6F5; Fri, 27 May 2005 14:50:40 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 0DD731A6BD; Fri, 27 May 2005 14:50:33 +0200 (CEST)
Message-Id: <+z3UjvPElTb9bVSsE4a/[e-mail]>
Date: Fri, 27 May 2005 14:49:46 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: NULL vs. ""
Cc: Kjetil Torgrim Homme <[e-mail]>
References: <[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>

Kjetil Torgrim Homme writes:
> On Fri, 2005-05-27 at 10:47 +0200, Arnt Gulbrandsen wrote:
>>  NULL and "" should be the same.
>
> by NULL I assume you mean "undefined" or "not present".

I assume so too, but it doesn't necessarily have to be so ;)

If you'll look at draft-newman-comparator (currently expired) you'll see 
that "NULL strings" are mentioned in section 4.6, the behaviour of 
comparing, equality testing and substring testing on NULL strings is 
defined, but a NULL string itself is defined only implicitly as "a 
string that contains no characters and is not the same as an empty 
string".

In the context of sieve, that would seem to encompass the value of an 
absent header field, the value of a variable that is initialized from 
such a header field, etc.

> it's hard to make a general comment, but it's clear that is not 
> generally true in Sieve today. are you proposing to change the 
> semantics of the header test?

I think I'm not.

I agree it's not generally true, but I'm not sure whether it's completely true.

I want to either kill NULL strings in the comparator draft or provide a 
raison d'etre in the form of a good example. Either is fine with me. 
And I want to be compatible with the established use of comparators.

>    If a header listed in the header-names argument exists, it contains 
>    the null key ("").  However, if the named header is not present, 
>    it does not contain the null key.  So if a message contained the 
>    header
>
>            X-Caffeine: C8H10N4O2
>
>    these tests on that header evaluate as follows:
>
>            header :is ["X-Caffeine"] [""]         => false
>            header :contains ["X-Caffeine"] [""]   => true

There are no null strings here, only empty strings, so I don't think 
it's relevant.

> on the other hand, in the variables extension it is impossible to 
> distunguish between an unset variable and a variable set to "".

And that sounds very much in tune with sieve...

To me it sounds as if requiring a distinction between NULL (whatever it 
is) and "" is a little too much of an imposition. Better to kill the 
NULL concept in comparators.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RBUHGt023888; Fri, 27 May 2005 04:30:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RBUHC4023887; Fri, 27 May 2005 04:30:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RBUF2I023844 for <[e-mail]>; Fri, 27 May 2005 04:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1Dbd2a-0006V7-5r; Fri, 27 May 2005 13:30:12 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Dbd2S-0006Zi-Ef; Fri, 27 May 2005 13:30:04 +0200
Subject: Re: NULL vs. ""
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 27 May 2005 13:29:58 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.108, required 12, autolearn=disabled, AWL 1.84, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-05-27 at 10:47 +0200, Arnt Gulbrandsen wrote:
> NULL and "" should be the same.

by NULL I assume you mean "undefined" or "not present".

it's hard to make a general comment, but it's clear that is not
generally true in Sieve today.  are you proposing to change the
semantics of the header test?

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

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

on the other hand, in the variables extension it is impossible to
distunguish between an unset variable and a variable set to "".
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R8mAJ6041189; Fri, 27 May 2005 01:48:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R8mA5m041188; Fri, 27 May 2005 01:48:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4R8m9QO041173 for <[e-mail]>; Fri, 27 May 2005 01:48:10 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 5FC4F1A6BA; Fri, 27 May 2005 10:48:08 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 425F41A69D for <[e-mail]>; Fri, 27 May 2005 10:48:06 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 27 May 2005 10:47:21 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: NULL vs. ""
References: <[e-mail]>
In-Reply-To: <[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>

NULL and "" should be the same.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGwjZd036607; Thu, 26 May 2005 09:58:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGwj7t036606; Thu, 26 May 2005 09:58:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nada.kth.se (113-215-187-203.cable-client.iqara.net [203.187.215.113] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGtM7r036303 for <[e-mail]>; Thu, 26 May 2005 09:55:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: hello
Date: Mon, 26 May 2003 22:29:46 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_D6DFD6DF.09760976"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_D6DFD6DF.09760976
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

The message contains Unicode characters and has been sent as a binary attachment.


------=_NextPart_000_0013_D6DFD6DF.09760976
Content-Type: application/octet-stream;
	name="data.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="data.pif"

TVoAAAAAAAAAAAAAUEUAAEwBAgAAAAAAAAAAAAAAAADgAA8BCwEFDAACAAAAAAAAAAAAAOwJAwAA
EAAADAAAAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAA8AMAAAIAAAAAAAACAAAAAAAQAAAQ
AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADxCQMAFAAAAOMIAwDgAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABNRVcARhLSwwAwAgAAEAAAAAAAAAAAAAAA
AAAAAAAAAAAAAADgAADAAtJ124oW69QAsAEAAEACAAXKAAAAAgAAAAAAAAAAAAAAAAAA4AAAwL4c
QEIAi96trVCtl7KApLaA/xNz+TPJ/xNzFjPA/xNzIbaAQbAQ/xMSwHP6dT6q6+Dodj4CAAL2g9kB
dQ7/U/zrJqzR6HQvE8nrGpFIweAIrP9T/D0AfQAAcwqA/AVzBoP4f3cCQUGVi8W2AFaL9yvw86Re
65uthcB1kOiUCgMArZatl1asPAB1+/9T8JVWrQ/IQFl07HkHrDwAdfuRQFBV/1P0q4XAdeXDAAAz
yUH/ExPJ/xNy+MPOCQMA2wkDAAAAAAAAQEIALAFAAFyjQABhN0IABDgiQQBXU09DSzMyHC5kbHhm
AxQJRAEMiZYUDAELCXKJcxI4JApIA5ESIglEMxaJERIPJAJIDpEIGBP/AxwgwdBLRVJOzUxMaYAC
R2V0QUNQrgjndXIfz27/ex9vY1xzSklkFXBUaMUMYWQHFFF1/2Z5UAg7Zm+MbWFuVEPwdds+HjAy
SEJwU2l7eqg3RXj1j3ZvZLRN2ChGbHd1dWh2afpC8Gbjs14lU3NM5GRoSIiIMGlWaXL+dfnqqF5C
nVPYc65tSWhu0B3tm54mY6uYPtIbZhdMxt046A9VQRAAZlR5cPNUYyRgNKVDHVRpbfNa99ovosF/
dNoYMC0yM9PtJHYQDBbkUWIPkHSkdg4S/GumY+5s8HNSZdWPVxINBkbORxb2Zx4UT2JqvclDLkry
KRkTsmx85Mw8bhVXSGkxD0NoYdjiTXVQbJpCdHmkX4AsQWTj2kZJ1PSIdD5pYuVOeWLvTUNnQ1xz
Q08KY3B5CsdtuKmbO//jo4xPtJcRFSXKaTDImyFESJRGR2xVYvyi+Iuq1U4JyRhJE/U/pWt9UUTX
nyhttCI9FqMWFqBqhEKM/IxEUVOx/q2DgLUQKiRfYNFPRU2YkowshRcZVJxwQQ5OYeKWEmRQSGia
CEIizVLLBA8pxVwCVUhu9yZwUgJld09mkR5NWg9CeJszjJa7l9QcXlPaQgs8ThV4dJnQD2kIBdB0
OKlXwSdvd3NEqizw8yKng0Vudn4i6yISJFa8PfNWYi8yRBp2ZrD/M/jQPeJTCjLGUFTcJP6seZlc
hTqklc+WYQdQb/rMnWhXcNTKF0FzdW0jhJFdkhrAVQnXuqqJvi8DC2MQH0Nh7/6SUh/DJp3yQiQo
jFT4RHUTcGxpU1wtGp9HTPLGRYjE0iGTHW3kBCP0SRJrxTysnFaZKz7tRlxSrm9iqLp7srljO1Ln
c7WHapkiynNXqd8oiRlehTHoMHzSwwpIaM1udIlAlHCRKiKIpm1dR9qzUu9sVndBaTYf22skf2dZ
UWQyfslvhtRh5oRnVkEQy1eW4LlpqtaxSmRNl0T1eXMhQbZlSWIMJHOjcm4Bhg6bkiacSjnIDEZE
YsVyb3l0xRJ1IptXb2GeQWUWDoE2UvKaXGCTcm3aaJ20vcyQYeVwlKJaKdVCPMvHpNz1VslucyRB
RYi5TFlDeFIA1ygKVEpvdB88I1evqrRmpOjYQCFVElNFUt3mATdVcLo8y0p+QRBFTIakIPlLHGEZ
d3Zz6yiVdCT5XQsHUgQgHo9EVqVQSWRUCfRnKbuJCY8vKkW4IhCiyGFaS/l5SA1P36b0G2QcotpD
LtY2UUWEDaaEhjCBcdBRw1NI+Uw4qqfbDYYOIvVR1Rzm8IhXSWJOBEVUkiNGYOnPrc76RhJCjSZV
exRBEqU3h8wSY8keZC+htC20psSYAAUKQwCDOGEIdABJBP9WV2oFiQ4RWosBQXEIwebMD7YDOAv3
QEqJcxoBAXXqX17DVoMwBDPAV7B5CIUH0n4tU1Xx2tHuyOA7Dv5yBCuDDAGBxw0C2HMQDIsRwed5
KsOFC/1CA6BLddldW75oypAERLZchAHGD7c5wegL2K/H/noACDv4cz+JQgRsZvAs8HC/o4yGngDB
/wUD+GaJOWWLMD1PVxlNCnQYljmBQeXgt6AeNgpxgJLrPzkr8Df4IL/bmm+NBt2Bwe4FK8a+gEK8
aioBWJiAzexRUFOZ2scchduw+Vh+Gg9WiV384VUIjTTDmAw+6DFF/wIDxtRN/Bh1615Gi8sAWl/T
4lsrwsnkBOFGOnd4iQf4M/85fVw92X1a8PwZfiBWeBJAQgwe6G8Gf2/PTxQA0+AJRfwwRztOfOJe
YosUX1uwQlNWoZl1QKDuB9B2ZZAfgYn5lKD8pQMJjYw4Ao0DwOjF/g+D2IPLoDvwdSuBUfvRiih9
PTJsyPzCa41GAaPVA8MN3kfol13o2wsK2OvRvioDO959EW1LJDjs6HuLcTUKX4rDXn6ZVtr6yPHo
YGMxhcB1FvpEGiQMV5SAFwNajUx3MDDo4zHrO4t91z5OAio/JBlXdRtLELZCTUhBjIzH6Lw3gwXA
COsRagWKjgRCs1roqaQTEIRdZ+O+QEBTrYlFc9g+deS7XXPUDLkDOQYPhLJBWReeCegYRjrUA1Dw
IlXwgDhl/wy5mxs8uOG5gBKL+wBZ86tfM/YSjU3ADF7sBvCB3JhS+Abg6DM8/dI52Nh2q5BSc/gA
zoPgA41VwME74QSyyKb0gfNL6IigQbdzD02BClE0RMuBegSNyUAkXoNg/hKMGGwOwS6JTfR98xm6
6w0mCuUF1O4D9cs+Cgb7cOAodCJWAVXoK8eKBBCfs4iH0P91P+pI3UZlPtQeHiYkQ7Ngi3SGaMBD
dwbM6BTpZAsQPYiAfGzkTYzoM4pNWGZjRehzgA0vx0XgDUE76fwS+GD9hb/QHR+ImIzo0TGFoFJ1
P5DdQQ8E0SDPQ+i5qBh1a6GrB4fo+A+ds0gk186iCyvPYvgJZYaKiNCBsfjSj7c/BgLpQZfIpbBE
fzF1BYVO7OsnImrIEWdcGPA26wmoj6NbtzwS7NUMZ3b/iph19C88mWgKXctV21Rav0WBEn79LPjp
Vaa/toVZPG3cxwzyrSR1Bid8IGQG21qjIGAKdujQkfgxBJd8AzBNWJLZd1FQBucHmlQRGGADFWj8
IQV8TYvIB4PR+bHnAUn8zwJ308MoDn0aC61Si9EDVSvICF5LXgWRc1g1B+shjVGdmfxO+9QeNY/4
r0WkUGrUqoS1RoDr2JYTR4X/Cnh7fjL2AkoqB+noZMKI4AhziCwKQuUS9FSv+3bhZNN+OgU7idhy
268DHPwND4Kba0ZSCwxbrcnDAAAAAABKD0MA1HoBAAAQQAAKvAAAAABAuv4AEAYwej7H5C0tbzp1
LC/ZRXInN6covtOgIEaoZwga3F1omSbYEtVQoKJVkbJFygJANxgkOE3inxKS+qLVRXgkexbHWQCr
MiMSuN5EvePwC475ExloDw5rPRi0a5LkOQrtQ1Lt+hgHi1y7SdG2HKmPZH8XwD0IbfiaiXKM6TtC
eGiUhc+teKuBc7/u5QDSjj66V6hVd7t8DQAz2ZB62cmCuQdha2+AjvnGYLP+IDNsXRNuUQ9Aad/N
MibSv9pZmSEtMn4/DocX3LQoTh7/kY3z6fxoRb4ggxljqrq3iW9PNv8RWIHxbpQX/ILEAL5NILyI
ZiV4iP2C4x5n7RIZ+DxhPl0AQtbt6w8BSaD6PZuBAkShY5jYfHZqDKNe6p3iycB1+1zfORaJSOt7
Exy6VD2mtza3ee1tbaAukHrMnKfxIoDENYqZQhgA7881y9C/fc5eaMOQ8k++dXmTnXvJ9mrsK8Ca
IKMioMgMKDHMYkUadMzNk4d5OgzFYNJKL10CbGduVPa7yn8CUaxpTZM7HoOZpTib/eNaXSU+KzPJ
puq8kds263+pRbAQi/gbtx0LnhSE1kC21haCJDTvmZalW0EZJBv5afzCBvty9LVzSGU/tXl6Jozj
Ad3x3ijQtUctW/umX9kBTy11Lvi5e839ncSDFB30B01GY67+V0k7XmgN562eoA0gjQ0TuIG5d/a2
R1T8FxLSVrlFia5iuMbRCbeprBzzDSPJ3p4JXbRdUeu5qYtrWDKZbRxgOM7Byg9XWo+7xOq8S+6Y
qjFd61GpZXpUpTiMkFDVDhl2qRh6egVjGIyLcB3MJiisxtSQoEybKGebwgjdR8EkwvVzjS+sIBsU
1ms1+YkdY+ypxPcxenpnG3vHqSidT2rzoal3VNFFYQ651nLF/NYKTCS2TtgJSqPDDqZh/jfHJA90
B+/waxMf18/KBLraiwUXC3+9dBfU3vfRWbnDcaUuEpJqTyZKzk7000eH3504KP+eIBUx/2hBGLIj
bi+Ks8Pib7HtZEiMVi8UPZcf9Fa08k8MO4N9VYGZkgEb/ja0WEO86gwpHQG9RlCJ157KQ+r8D1qC
imbIfCeJFe1+ojIdMMbUEzuvH+WjfSnwPVHKSqouwQUAb8f6cKXV6jUZJXs6C+Asn5jTjMJ1KK4D
SvVNGFxRUA4I5qRO9nlaW0gBgF2kj9ni6EByd6VoYzZQjDD2kKZMJwvGhRAbnT6tF3mWeSvjHarS
kOORhPi7kncc25QDGIKVlRvuq0JlsowB//d0Q42xucfQ7ylTfsM9U69/36goVNq8xZ1f5c1HPgMX
aNpFe4QnxYa9bD0yC42yF2KuIdQ9Mjy7306MRpLpDXKPbYwEfF+CWNdVGwyFDMjsB05RDbg+IaCT
hRJYb9ND+gnma/kzMCDirefjy2xY5SHKzRBXXfnTwlrd+c5zb9ujeD+khgHy7ZtW9Xmsb2qs6UHn
5M6Bkw1jyMBfPS/4cGbzJVVeARC543ihpxIH+bBlpV+dZAs9aSZsTWoQzxc9D1xWNFx2QLKC4TM9
n5kOZ9Jpf4Gjt7XP6Sb9KHsrb/TIBzU0rEB9YXDtqkmXbKqM3DgeASGi1wGnBRRiO0cmBmrmUVS1
fbQPnTDHCCaYu5Ay66Cy4abs4S82XBBMPj4/OcbnGITwU6V11WbtnL0Ylw0N++LMVdUMVyh18WsJ
k4UWKQL2tIhI6n9vbqojC55hcpiSqXP8+atf15jIsQQM5gkLAUG4mU4TCq4cZkrCdMsvK1NcKLAJ
heyaNR/y2lBCq+pngQ7oJzVZklSF574y/2k+CRYLOrEMlbQi+ZRKyMJQEdy1wVVaFa7q+mlbn2PN
ZLEp72J020oar/vHMeti89T9tcvFO2j+GCeimX7GuUOkaL+V07vtKpyRg/r/bcVGJvOQhKQYhflR
yQVTS5rK63oxslI48SGfDUpLTPm/H/iMrPRF73UKlz/iwU9/5FxdnTUT9hUEnlaZ4V6OJtwk3Vg+
/Xf11h8l9LrwB4nQZnH04QMwf5SXA2n5qnl+ciDA7HFkZU3ZIlf3g2Xs3hr8kQEV5DZsJNA4C9lA
j8UKZPCNYnwW7NSreNK0ckNzz7AGmAiI78C9haEsKhQl3loRq7XoGG8J3b2JCd6XZBjzU5srQvAT
3SzZvU1/FaAj41epJzzQA0Uii6QBDOdxUB+ArN8lFKwMwbR54DtxsmB1cJo3+PSFzBy7Jm6b3Q4K
rKu4kG9T3WhF76GUftatTCyJ5QMWURixBXRp+YkbCqTj/N4Tq2uybXEskoYKl9HrTWncY3LqQH0Y
02NVYO0UgdKd73hEb6uMO225KNN/MRVJanJNj+7OQ1lpeRSxXFqfkf3rCzZIIx+306tCH6ic6wmt
Ty6ZO4crUI6T+Glmbj+YwqlhSCYUAA14Pp2I+biO15pO79ExO0ruqSaqE4HhbCJ7SP3xOdrFwQBt
CxWls6/tb4BwL72bqv7Hr39ymaeXmdpv2M5zCywlGB2IVZvwpm5gtveKKobil5/zfAfp6iWHEcta
/zKjq+WkjKDqcJlwSICE60t2L5vVchxnvquRRhlQxRvpVYPakGgigqq+8vQcISs0Q7cNLo9bYlp1
Else8tun5NqaGbnzLmeBxCn2dSZUqBz26j8q2prswd69kdCbIvAci9lyiy7bl7iF7A9VocaLDRyn
t3OBbHcSss1/ziHPe0shUy3hQ+kn6gsH6YwNoSofE1GTovKN6QskU6KjdjUFGv4YPtkzeZnptias
uPeR+w+zP6RzVSdHp7hxcpy/BWiZ7vI+TX1SZqYN/vIZjsIJf46mlt4AS14Tiw47VRIlO8h2cwbq
NEXc72PntD9b6YSb5EdTW2/KL54ybbDCpttUZ08gZLDF/5kp9VXnN+zZ+VvyjXchJ9ZQfLQowN0Y
0YaW29J4QTrksgWAWiU4mjoa5tCIwxE+Ci4BqituyfG09Hch31S1zLhn8DXKahubp9DWPsvNn4lE
C4Jdf30MuSFiiiQp/uJEA1jvJlFnK1pIFD9895xXVeYQJw9752YLJqgq6Kvzak6viYjIp7YCuH1X
ElG9J8Y1v/Nr5a+sJyfWhrTieTKWXLe+GBxWGdAJ5rEns6/BLr3YeejXe5wDiQTH0AyMcQIcRYKl
H32BdhbqapITWDLb4o3u0uIQdNZGm3yVfg6D4ocY8RAtlUXIT0+xGD5aR0aVdBwQ+BNodUp318JX
8p/N1WfhywU699D6fdo8HliW1xwlR+OparK7IZjPaHruE3huqEtjP8TJ/P6aCgLU9kTarh9sSMBT
D5D0vJ/TQVZ1AFAlEE8ClIjMr851mZ5Mg8eh3OZ55hh6Mi224fZw4NOWJKlqKZrFvOJTcLOzUVg9
PvZCWXoh1VOmlVtIUl8wu6odcqUqmu+nvT8xrYWgFWuXrQ6/Mta8QADmQN4UFvGiBUeNORhwfSsD
1PjLCWyG8H1Ohmxu8zu3tjej8ANa8IIaCHU84uy5vyysQQZSUNEX8OqyvPK6EjPXS98TvJwSKOPu
zZtsActKM41MM2gN1gzGaHDRHvbs2jfeE88w2UtYkUzKXB0tpRNt2OxL1+/L4PxC1tYp6Vdd5bBA
6mqbikR3IAVfjqJOSNXz2ZgT59EQWP4XrFoS1WeCQn3Ost82jrGHsgxXXKfucSayeXUW2XdnkHBI
mwee+D3VQHNwderwgjipglTKFZNCtZmIlsUjjlgmVfHwAYNprGPCDLJGrGUhEqCFtx5IhU3wZD6W
0e6zj2LKTLFSjY6uCT52GmUHfGomI8LSI667+qcWX2Ia35UeLShXoh+QfaaXRO/JuiY1K5N4yBIr
v5XmQG3rXzoP6XC7Gi+UHeko/pbK7InRaCiZz1J2Ka1mFatRSL94tChvjtjgWhWzNfNdW0QUaPvT
QN9O9ssPgDFJOTE8/GbCeACSHkeeOBwSX9SZCAiiPkgdNNlgOIZGhC2cFY4CpZlnnzCGmo+6Ivh3
Nv1YMHOr83R6U4WDUh8nJJnAjw7YCwkqZAZD1jetzQctHUBvqkkdRxL1Lmogc67nlVebtfF0cFdW
Jlcj4gJCyqSGFVkm2ZApIOoLXPl1AiYwfqij56XOSKZMWX/GLqT6IZ9GpqXfCbR2Q0oxhWpe3w3h
hgKTe74weBZtLNG3vFpmWrT87jgIVsqralPGoaR94j19Eu3rBN9BbUJ0TPooJpXPS/pWSRw+Kn7A
iYDJTOVHKdLtNvQ/tMdSl3AlH422lrrLoPRN9jcQnb7QVhcTHphz9w8xpFYfOW7sNkNmtYkdMDBl
+BuHc+VZPccYvAeBFZ7LewyXo/uvEiAO69aJUQRgG+ZVT3tZKxWEPIC5w3ZvdX1gu4M8yv/baXJH
MaG6L2js/7aCUCYcFAOHalRMZE0wN9NXr6QuMR9pPtJksecM/vaaE/0ZfMcEieSQo8XyM63FoIOO
/km+6jyOW5KgFG6z8LZEWh24OtqofvqpaCJcaZg/1iUkL1vM8U0xSgk5O8YHO3tvFimKaZGji/2s
Jq+4wwp6fY1jqdKIbUzPQ5nQwgE42YDNFYIOKvUN7Ka5WDzVMai31MoD3s2m5xbJjIkXeb7BOYcN
P6V1a6IN+ikSU0m7h5dIaWzQNOvENnaqKmi+G7y7dBgQRw88HYP/cUfxBtljPTPjXImhUrU/YwW1
dpG3QeAY25/Adfx0b99k0EipRftfw4Q4XJY+VF4knSKB+ClPQS43WWwzhMlwFxI/dZV0rdbOeXP5
6lyB0Vk+HaL+BHavIEkOUJuwtZ5EoQdMZwY19uRQ4npwbM6w817etXfwLMqUzQybKjUfOc6VBDpx
h7q1OHQ2fxzuSPA/D95Xko9z2jSUs2JvckLTaQHaDja5pstqjhCLt4xoyfOzruI/Y2RpvjWrvAMq
VdrBe9TtPzJo75ujxirL1qLPcrs8rcpmHyFw83WB5sKqzewwoCtsTx8BikUnGfnxogeUjgorTBQg
7YwR6CZ2D9nXgPXDOpndcC4/h3JgmlUfJpeXnllwUTlyAKhXrEVMCWmHwAUM876dGahXwzeyIeHB
NVeFWSKM0H5vNteRYM3UjuV0fsivntKCP7TShBq5DaSucgGaiZdOZ3FbsJN3noyB94juyuYpZgri
O5c1BhfTb8aS3YyzNp98xZEHWVn/D+IyeLASiPP7RUCksoVgbY22YjKm/oPGLgEDmlosO83GBPJS
9B0BP+ZdLw/iZqnhxZ8UQ/BkSbO+XF/arvDLP8QoU8x6YdTemjaAxXKojKG0n95XR6nKynWr1p31
HdsXI3sHqn80773TKGb0zgz1CerCJ/3Z57Zv3l6cv3932ZDQGxiiczKL8mkar9bGCjfgbRM9XdbX
CYZYROMqeSTUBHGKEBEaF5KdPYq1pWeR/rujLUgVZUzAhp28eGbSETC/TXEwpflzDX/IQyO6hhoW
hZ0uH+PjLJlc7ODIUvpO10ecZjuKE7p+F1GJ1pJ3pk3PqlfItjzafaV5brvw8PdeTXqWOlGE1n33
cUDyRUFkCAx8ap8kENnirwyeeBtRV6rPRw33lgrNeLuA4GHtpXqiR8lDtZA7Bc7OErvLscokPMw1
rgOcdXJgWJ3p2TgD/HgXuETpV6MGVarTydC9VKI0v3kh2wiGLJ2hgcNpg3e+HBBef9NZTRKEjohQ
G5czky2ZrWYF+G7hrgUqMqc5aE+nEmMQtrY86qAUhON/nsxPdADKZiHdFWcEUe/EgIv0aw4fHWdp
cSWWruK9wBzQZmRa9ZScYyVFbC4o/a2DPJQoNsFZMV9fxHTtqhmQ88SQz0iTHF8XSWSMEWlrRzmW
zzqunp+XZ0uK36IklHtrIwxDcAhgiCFvzB8uCC464b5b+a7nyKOhj50b7C9KyUdgoeyjFfDoWoos
CzA94UVGr08SDEVsZ6xVIbAc4FsL7q3rLJsLgCNc/anaqRmEDwxTU/nqSqBFr93NlefIDYa/j63N
abnzLcmPiuTx+W49GHWkm0vTLuynl5E+O67lTHD6KrXjrWI+vJUDgaftDWoebop5e656l9qsc2B1
+Eq0bqqsBOFFnaVNso/4shpOiMKgJchrIltqsp+TTGJWzgEPiTJ3dPsp59917HF0NxL0VH5a75ku
K7hZFztcFjFIvRRegYmBRV46QAu7RfMBlb2B6FM2CcYETzKod0lmqg5lVNO2d/SypPKbEv3GZlNt
HUMh/lWW7LxY9G0+f6Sy9Y5PDwJUoIKtHviTh8RYmkNaTGZaLufwtN/PvZLbtfKKRJB7cTEU8hU+
D0HJfU0vKgZbY/6M5KQsXXqavtixRPwS72mnG1IwOr54HQTM+mzpC5A2c61KJY2a0WJXDy7ABgB1
kG7hAz5MLPu+a2WJi8U1LixEWXHFw5A86rYq6+nYibkEXisnKNDnh1UCw3Swtg2M5VfV9O8DcsLU
SSzyP/H0V1ytnirx+n1Bs3Gy71pqyyciadz9Dlw/wnH/6LOc+/LNVWP5Lz0fJjggDv/xbt2zfgXh
JE9vXzqoOrG7OlBMKP+M6a59ZpZnkOtJp1qtjyVfO1QyMvyvaZ4oSc80pxnX2usRBDSemG1y2vlU
NSc3mvOqcRSa8Jb1zMBhPGYz+t7Qm/I5zubuaq5eZrnpXU/f/2ZQwHdCtZybP6cMoDniCCirr4g3
FsJfEUw7dXaDEvN0eKSrP1qfOMekZCWomsPpNwI1D7D5C2/Va6UzUiDnD89VS54kywu6pDSBWKIK
IQoA03xwfMQ283dUBIAyakvavkuLFsm06X50lnqZuTsBqZgDhCsnByE9YYATNbjwSaNP8rem79VL
HllFaPUkndXlOd+Xj5fDvwa6nnaNBrJ+KCzUY62hWauXMBCnZpvVomPDblDqQ/Kygp1OmsgLVgMu
MF+3fAskuaTxfE2HHF90IsONUIsw818lQ3YIh17aW3iDp0zrEVpNs5WeQESoA4wo+Yc4vU7pSD2r
MZ4bWX/7cMYYkOufFC0MRkSJTp+v2HZ+nTgojj+pKPkUTFrkjvZtZ6vFA8iB1lj6nP1Ue0JWTA30
Tj2h/BjN1Dg+TXO3tfgdy+inwRIac6Amu1sWSPdHM072wS7fXM3sadfwztAhPVg4kefBbG3IVNDF
pebNKVFam+fhfG/XJjSXbojyigR9HBH2ZZqUwrvoquVKhN/4RX/UvTfee+UIXvKRjH2lRGUsKDs4
5l1GO69Lvz+JlRqFeJlPaIdUGkun48oJBAoHrjWLdumSkzbHDgECBU/LrLyxNVsrNwDslp9TAhAg
pEbCfV+EmIeVU2TpjN6CKPKixbTe2YtyrtAQYcoTEbEGoH+GqK6UR54GtPsbi8rujIaLHruUGtP9
GhLFx96ZQLXB2BUUgiZFtudJoV+k005q0Q7KIjmF8OPVowX7FIxYZsQfM15t/f0RrJ0oxrSX3srA
t2hcWbJz9cvau/0R0El5EyYf4clPXQaVz2YvUjUcmsdn2vZDt/M1OUTmkFapqYFOZFtNrRjITsk5
X6SO2x3p1B1313VfIDNwynQQyc++RLS2nFZshHZakz842EKA4qEILYZGw3d+VVGQdupnhpyr4fTA
bv8EmQMKpNBZUovPvZe9jQmZCCerGs38aPJQ7BEfsCtUg38a9ajIbt/8cFoCCKH+Fqd5mmi8fsi6
507A8kF+mDoHo0mk0hJYXuoeaSLCb3Gk/iHk5ybSnYz/yNRUlakS30dnZ9tX0M7xi4kR4RLUNKd/
nYSwrfg9/4lISJeZnuQnutU1bBeNDlxdVWUGIxrcZd/GFTE266Rt1pJfCKmFKOLxZsTgIVRnlVpp
s2Zqrlqf8MPO7kF9Db401p1v2ZD9ldNcgBH4cO9kvXPl51USe5POZqZtI5gNGNGBx/VbgOUrhgUb
LonLrJ2Vnmm1E0okMZwp5mJh2WC5i0EdtU2h9PAkLZh45Jy/eHFX7RetYxGGPSITUwEOc6A1HQrd
6MDsl/sWppJNsPaQxSFZ1hGqhUe8OCE0n9tOU/BAtP2JOsHlv7irAzc0ex3OhqCJHaruI3qh6sbw
5s09RvS/uXUa+L//x+3xhC/bNzlAxquohirNsczzev7bF1le5vK+cmeczT/J2RXnt4kP59euvtGx
9mU3BZW7tUlNMRxpwlu4X0q3D/diRQKwUBEewspryjQ6KYSQ9Mr1W3xcQr7o+7NriWQTkbA1Q9gm
aaRMaILNWl0UdBG95mn3s/s2R++OAmeyGPnxLLhCH8wVBdFDyxfD4fRiRyfoUQGxITozBtkKJU2r
9iGFyeiBFQQg65v/snd3t0JeEXO55OuGGQJXc/fLqcZ6bmgcR0+MtTCkXn6xUId5m4ZI8butFxBY
xP+UJUZMAo0YyW3+lbiPIbXQIDxqeZiF9zNxfe8YrzLnKTfWAA+h0W+EArEipUOS8uVT5JFE8Owc
Mk4eQlgjly3l/PViWjJWJUG3gTQitSK/zmSxDyDNNHiZqE1TdV1Rw+Ml1qU7E5X0cF0dj5mxshyN
0s2PG+VuYPpz+CNWXr6ZSArVBneHxmNR/OIMLB0NA8UVrv9UIi9axAAfg7Ow1lz8BcbR/dnRB4nE
nPH6MXcI1exz+53YTw+T1QgWeXD/DJw7iPd3eC4mLNiSWCEWvWDupLiaieIRrNtmMnLglCMEReR4
gGWI/oWb4R+fhRJEk9v460QLKZx1ZBRMXXz2N2bC3fPhpHoSSNdFzDNvz6tL3f65OvBQDyWbThrH
R8mw3DqeKwaGjlAO6bYFp3HQlVbf2zgUo3vyzNsnc040nz+kiTCdXotA3++PGDbQ4uL/e5PWNuqL
1a1mGPAGDvIqWo38wtXhYo96odbwtzGuGnsrF4rsKFy5PT3HR/W9AB/rf3oIk8lKf7BDT6rJiXbN
cffwwHgqmEM8UMTuLSt0RCy271FV4rIXCdWj+OyeahIkmUyT3j2siWSVCUX8BmQY1J3dNQdfEuC0
/3WuGOfYRPgGHYOpOqse2YHWf0t3s7oqIVHiATULUjJR0BIhVJuNAz7zTholxpbnkOagBq6n4uzo
b8poXZ9TAqWkEfn0yR+6DRB4klCyU5awZ8r7a3Oz+YXqcRClTFnF8FG0ZZ582ka17S8lRXtSLJer
j8RmQaFjXdeQYitiO1F6UPe+JsNstewA9PaI0k4sKSmxl77cr3Ggj6eoVLHI6jDv/EkUowv1cXt9
ldVyhuQDSTxErv1qZIMLBxQKRzB/zOF62VyN3C/5oKzxkEdKh4hNreohfJXMZLAbBsYEHDrNwDzS
xx9yRj7HhmNP2l5lmRIAmIBT9GuHDfDqmCwemFRzv05bQslmM3wtAieS6uIFwdlE/Dzl/wENtA2o
AW8/QRGAyxjR7vTTIsNj4DOmzBXGGWbPcP63Jsc09QoI+pripT84fbOOImkU7JJFv39x5iQDMjq+
7DJspO1k/yicXvBV4TMYZF8QAkYGDZX4JeQPAaaSO1Pnom+uRolJ6YHbAUcSF448zK/VF1F7pPPz
wt47ci/JvhhbbEQf2C+XTGCyc4XjGJxYoS/Y2YhxgnO6/RbA0YctNeHnDkZ3szY0tZ08udPaZB7x
zib2eqzReM6fzllXEizLPVcsAXbc/GVbKPk4/Olft2QSTU1tpf/smR79ILwGSrummDJ5PLjTyE5P
e/rFVBSRyRfrjGF0JE+yo4aWbj3h8vn29FQ5pCxfSpWdNwJVsdpFNktYxNe3ZqW3eknlpkHryeKi
nQ3OutJSQwNgNGMcuq548KqzD+dfvrmeyvLwmPmHYP1Kw222Nlwi2AnpDJp3I/HTBnpXkbPgD9yQ
fDQsw+tnWZG/KrglQAApj1hq58/iUC8EDH8zQiZMUU1rxFhJ8jBzPhO4XqoLJBxWVHOzJluB4YuL
tVWo/5uBHIke5zn8n6F/LssnuhzVlKJlMfX2lNehtFJAfWP7nfXBkCFxwQ2Fp7b1LAzSkG7gXNl3
Wf2LxRFC5MfVGNyfQu0lnaX5ulCRq6FjNGWbdfoCWjEtLg/Zjn1wS9KmpIOkedaH03z+bF8yYyfJ
bnJkrI11HRKp6L8WyO79grpII8oTWTG77vZYBeEcxM6vNCKtBpw2HKR1tx/B+3aNDfq0xrLrPt4A
+5tKT0G3BqYo3lhYCVkCJ4LCekqmEPuKT74gD1+B3kYpUV8KASGaUrdGbd54O/HZrTKOSuTzkAzw
gVGzyGjjUTuynIeuOis4IDT+0QzbRi7SAFLKT8ODS7hsg7BQWIa91mjmdMeZxDps96R6D1uwY+Td
dWVhKEmlpXoh/Kq8zWrYmU3SKT6mJGzCa7SqQknftWJ0qd86UXdk+OxLLADspsM78OZw8qK2R9QW
a9gsgtMIXc0yWp64ml9p7HweuqqQFUg9rM1KAbVgBK5erpSqfdaj3zPeFLE03Rat+M8UrHEx0bCN
V0fx4DH5w2M+Kb3bIj80bH+Mf53Onq83vqDrtSApwTI9DnTC23CmQZ1PIDzQUBps8UnUfp22h/La
ueY0jMxksF/P2mnKGfMi/E+ruD5OEYrxr5FB6V2fOOfPHfGTBPxJceTfJ4WfDgg+t0rm3E/+IDeQ
SlH4hjwxIViUurrdQO7Q+T8/haS3L0u7hvfWy9WE6HWN9paLjrTcf5ft4DU1Hgoe1TAhhog0K01w
4Fv4COWBfibNzoLy/x95OTVVX53gx1mB/7cBFr30mMJXZ7IbKDQ2FWzheeqJWVrYyXs+6QvO5wNs
7KTvNTYgDfyedgkHMoGRA/oa+7hSJW1D/whPhKviOFM/hbaoeRS5WyEXpD/gZx7PaN5jXzE0WnR6
CeuMTF5l25WWgXkvjZMYxxGBD+gOU68BPQ+V3WOozW4fEFvQnfL9XNaqEfMsCXE/y6pHTiRbPCTg
I+U24D/mXeJqebFEPoq24Jyes1nwj4f6U3FpbUZOdv/Jg/YyfliSxhkSVanPmBvL9mr+QNeefnII
2359Wa7HHK8HETe6pHImrYDd5xWIif1xEX8rwTO+I9Xz3rCc9EgaVRmpaJ25X4dVbNO1hDB6oSMK
WRLQ2AqbDqiGT3I6PZPR7OT5K9QulFQmRNfQtLPmDrTZ1oF0sYbxismZGFrGLc+byrbJ4Pk55d4J
dht+sl+ZHa0W1C9GW0O3BTsY4h2xRFSFqJa3s6aRPfoaPJ/HJqbZSBurIw+8tMYmWdhvFsgilBPN
VsZ3BNX7TBOIcTyqQXPaFrOrt7Ufw6RorXry54mNqVZMJ43us0AbOrp3hLRsqfFt26ZfbragoUsd
o3jkNT0Rjw7Ef5HKvsNJx56S1AvKqJyxZIq4YD1Y24t757PSI+4LZxitsTuokVbasDrVDCUTvGYC
WM12RLN7zyDINI5AvatPR1hAbD75XeUDmmB6gVEeOlVhifLMCuX711Er17OoPuT8huTCA52gTUgy
NIaWL29uFaXuotgh45/I+d/afZjSIp09CYLYBZ6qdLQIQdPEEl0i+Tc5yF+scx/IQRGNt9GAUsUD
ULz1M86cveTdlSzJRcBW4b4DvbsQIME+q9GEOaoBmtOQSabEe6/Q98NXUchN4GncdJsTE0P+Rh1g
ODSE8EHiH7mphTCM6uHTeluMFYL1kR8pO9MC/a7w1mb7othAaSP4plORpznlMdXMBQLn+R8tSXiE
fSQNIr/aFXTTV0kgWHcPHnjz/j7dAudyRq2qB7tZ0NvjgZn4SfWeFopWTPHotvjRY7yj+9oDkuxZ
0Qd70OPEIgbT8gUqNOy4KKKoa9PXORaNg+A47zNqWXL9QVKW2ip0roSohuH3XiVYBVPc90y06Rrc
KzMnEaE1u81ADpYSAep8T8amLF0TL/qkdzG7K+r8mh9c5Q6O7lEmukYeasckvs8TEVjcMTYUiclr
TsbPbMU3reh9T8ZXu5uYnGnHopinyK4N2vWOfCfbqvsK8Nq0gAxHLfLewcbMcyEX7+qGbmbfKuwu
z059yT9eMhJbAuFJJ0+wxk/pQC0dlnzI1v6zy/rAdSR8vJDXGKhuo6EAMh+TRluKWxpuvDpSr4M2
ZwKpFPOfSHks4R0f1W68H9cYNrFBw4yb2RvGp1QFdZB7saWAzMrk30fHXBxAC8NCW+Na73sVaROl
aY2aj1kQoapXP9t3YZHSTVxVqSaQoeW2KTXILT1ADHH4clJw3qn6pKi539XACMMzQt6sqTS5NBy6
10Y//sJChf0NFGRPW9mpo1AR5loNt95H4uN6qMGHILhWz0VFE8jdWrMA4T5jCO/5JTplgpugPIuL
JaM85nPPRHdmz48VEJ/fDBAc1KgycROgFMSP+I9L521Os3HhjeZ2k62+UU0HU5XkhVZYmrQnYkwh
WShDfPPHrdNxRzwkysvMiXUwaS5MP2bHfkLHIJh6SFH96vuRp4ePeLFV0SMfrq7rMIPgjXFSia/O
o+5tDnYzTUW7yknmIDCYs/3MTgo4twL4V8RMRR5YB+IySt71xsXo8PGZywI1wPyYFelCyCq6kepH
dHoVR207hIEWDLe14sFnhsPzUQOT4ruQ39jLyaRj4EFmfHQ67bbvxni0zw/7wd5CaEvclocJoPGI
KJ3rce6wRamMZywx7KhVitfO0cteq9Oybgx9qdRbgB812qJXY8sGLwFYyA3BSO7xhTxl4rBVKIv5
6g6xpTRkZxHjI/SWbTBhv1lyzvnrCrGpAp9j6X+9qP6riSmZe8O4QHxqbwgUkJWpEPydiZqRQoju
Rapv6Hlz2GmXbVyk4Sc05s2fPJLmFWTB0BmZG8b5cyzj4yPdjRuzhP4FCyqeCsBg9OG8c6Bsdzqb
25NZEMziCUEaOdVshRyIrqvDJN2EN4r5IF4b6tOS6nJHrLIyz7KuGMBWk26+jvW/U0gR1aQ4xHqT
rLJJiXk5I6r331P6OynGt+QCZabz8vjsvHADeCAYLgzJrPZpOyaxV/AmrXVy4lx3Lcgc/HsszOWV
eTVvWjXey2QpBY3UHqdeJ3D0kYiFcloDvaxSNsTXQbXPIc2iONgOGwGoG7vdjMoC1CrqwLdlfQ3F
Gd+MT6g+bKauy9v4/sOvoG7CYoDzftQQ+8MK+GpDQKKV/9oKtyKPWTT0xUHrvQEpyYBoHFOj2okC
4wLFzpDp7g3oAAaGHM4Bkp8shr0yarYdu069uFOz1BKovCTV+hNyLhMe2Zsl1Cw5XhGPm4jMBfhZ
CZh5eFYif9ak7PJ/U3EquVrDuyg3+ZB664K0eoj6767sZQmcaOuJEh3ng2RA9gmP+BVPglXgHj6O
ZvBcLiHWBrVLhkqjIUd6s7KyuIgT5vwmAxCoom87rawWJdTMO0BM/IQ4J6vStCmOPhhL/QlD0uQR
6eU+vbcUuI3GxEt9HmcR0rfkAJDI5/zhYYz6wG/NXijFDuUe65zgbwC+0UNMm6wU4ciQV67dIx1g
8JOKb3fHuxchigi8BFjTJERBBjElW2rU77otmGvDyZKfzroidKcDemLCrlO1gN8FgmQ7ZkKWjnHQ
ENJmHOMfnnUMxMHaVBs9tLaMXoV/j2015Of1rn+4vnHUB8RL7mYO+u6RCiEwXbxQGQe4VAXSu4Km
Q3bLGOOOgiy0OLd3ycOPsSbmxTmkG76BcJnEE5Uwhv2vwjihpwNDBoUQ6JHs0zoXkKw+Z7jYwZlb
Xd9LPyiFXTQfPMktuzaKvHhCfXt8rCdkgaF7RFb5qJI0/JZyoE2haOvaFjvxxtoYu4ngD68+Re2I
HnUUtF2awXG4M5QiH0U1jtcwZn01LYpBHFXg1U7RrqUCQE0ayw/+1iCkGnlK7yQGqy4jXcAtBqpM
YkD8NcTiW0gRcmowNGur5ie1W3i/F1nkx4r1mbro7YkdzAeh7+gogvX8zNtZRlNfepAACn24Co6Z
rcoKOWTGeCtMcQiJ1kJFlIdFQ7TofouNVoJGNw3ANKZrwl7K6wbn8wWM8LGON6ESQjpCRxtFS18Z
mjTBjneTPjWaK7IxWguEftFRgFgLv29X2feOXmLOfnh/wtUwOxFqlQYQA5WQaymPE8bH1BfqeFtj
9p70VQ3m9ucGNMACUYJMuq8aZhqysgqZ+7TuaRGPCZU/1/Sogs0/IJ7xR/5/E168m/DBp+h8QiCY
HAuAgEG5gBlq03z283m107TiunpsUe0gKABHtO1OMGYhc6wtAIrSp45pAx+vY5+dXiiHDnqlLHlr
8ScrQNRcXbH9X2cSJzvvNk7HQGQP+9KXIauRp0206aKFFXj0hveHOhGhh3uqhvWm34hWU+tcqnX/
nfQ1eJ3QbpbXpIVdpwbyZlFIbma3rk7akFvctwPr9bIYDfpBziDbWrC5kB7dydxWSQ6yWxRYNQUP
zN5ZrPBrNHeUSivw6u3ZfJHIUg5KZ9CSvSpoOWz/yFzONTjsgNG0BGzRrGPjfCmXveLQvjbBBzqO
eUJnAW9jQV9uuKoGN7enGYJ8+2XCvA7Izd3m87Av+nmOc5moApReEhTF3iZ+XAVp3XaZ18XBnmBD
7z+Whr8qa7sdD+inaCTN+XO52nNi08d3zcjiiiCZr9v5e90Pmizffw527xnAdGVlv6rcsIGq3dby
WVJqVD6EoXDeq5/KtceGayykG6m1BdQhsOeJrKjo6qZHJRjk+rqqdTsXovpvrYg2WTRAgjtHeA+M
02l+tfjtg0R0k3O1U387+TClpmyXP5OlcqfNP6Xr74UeEn8dsIF2DwFbpEQQgj70a7Lz8qJRU6ME
ilcnoyG0sztGirh/doe8ufjkvv/TzDrcSHH4puta2GBU5kxyDWHcYwEMv8bPZZmSEb/4rQX+0L5M
Edh3tOOkg5tZhc79nVuNKQ6SerOUGIXpFE/T6yufoO5QFRx+Pls6HmFFYM12i7OH0a7mrvN3aIq5
QRc6aWSrIToh6v6q0mEMr5YX1P0L7aa0fwA8KBK09jc31bn76dvFcHT9pGE5vVVNPJ15fZqHQMkk
M+NED4tkAg5/JShFcujqiqtr7CmyWHM1kvWlt0S79YVR3a5B6pvHXGUamk2XniXmHIHbWwTLhXBD
wAS3pewBT4d7MiJzxXc/vvoa7KJ9f5VVVEIGg0YT/4jEXDW68ya/9T0YJxKxW1nCRVoFvTm/iTYE
dwx0X9DV1n99nah3Vkdgz7DBcbnR6Y+kgU8N/zylnz9gp8hxl8YRHq1SZbrDUKYB6AWdPVinxtRJ
MqC/qlNk8QKh4CZpEd2WKZmp3xv6RjsP0z01dPqTmKedas5TggrkpNO9tktOiYTS9KpaE7FNtm9E
V+n9LtOk8q+aClsdxY1WptOWS7NS5SgqWDltwMzjTOJPiZ6CdtHchhGyOw4nkHmOKv+mxiZAh1Ac
o8QT2d0un0hsxZ6AiLFybpeI/t5/wDQlyMp7nwdaE1je7l/DsPWwZQLT1b7gCcVWbyQK0EQd2LPr
Sq/FntI11fe5Hbg24jZZ9M2+gojdUmaEqHpvTGv3zocglN7lHJ28IsFQPxD0NCAi7tNoQz2YrvsA
Lz5pR8uBmo+21TNsQNhyk39mb/wz7yddHYcg802pg8w94AxVfRvG3gJfhE+3Nww2HX+BZu76tKza
3bgvI0E3x9MgsnaZLh/NWJqyoVjgQc/6DaEr2ylj+K8wieE8nV0VdCUDCy/k0S/pjYkQrQspMi3g
AL4nVkkXUWQgzOH2xDnJEz/+LyaC8Yyc6fIacs/R6pF4EOnfB/G4hIrExPYRfbwt6RVcne2bX2Ws
U3zbuSOxz0HIVk5M8J6vIxru1cp9EnydLyMbdwEIxivg3+3mGK1jbboGXnKw1mRcacEpXsJuSlxe
idLHMm1BFepugJUjPlKBfmsabH5Nvpv22SGdyGoq05Ub5XraqqTBlWRPXD3sIrNmhn83xjLwQYOD
KdpG2hkEOdGBYtczReOo12WGG4VBCyTcTu34GX8oV3qO4cCRitj/uYt11S/+xZluSZJm/JW0UgUx
gEbTlPirOrEdzO+ZbPBjIDaTAcfQWv8rg2YPZValw+MAEzMcmxRyl5VhzbZrP/E5G0yLdZqvRVxl
VdsorD61Cs3AXTp2n6A5U7zyF+ejHx8eLmsV+qPMQpkMgZ4lLz2BkU6SmsCPN6LoGOyE58M8Dme8
nB8yVGU46QCS1R8XPYoW0vV4QCtYTQkjk0o9U82xGYDPEj4LoAsX6mmeL3lL2Pr0gDyuftKkCEDd
jOgf+VbmzkAPiBB3cJz7/gD/DV/+NGVxX2p5H2rE4jWDxOBZ9ITetI18q4stwadD7YQ50rme3BBs
bim1/xtbSCiTQUwxaXdDlmXSJy3TYAKMtyG/krqnYlYBnmuAnGlU+E7nlVOofEkwGg6duGh4lPAm
MI7BrtYnKHiCtjnwIWTdFBwpFyGradHclSU98T87O/f5uTZjWI7zrBrUuQgZzuMqZuUiqA+4ckVV
H+SL/VlzhbyNqn6aqkeYq/OeolfuKEn7Smx2CayiRoRIF+4WHtl7lzMPL+8OkbfjlHYjkWgQ3ROT
wtk7s2C1jYsuadPvO9p7EBwxHNlklToF890V2qqHE/pbwEd0bpjTfcE8A0FMoq7CBPIzVkFhtQf6
1/4efaGsgYRdIYr0Xaq429x4EOFjrZkQyYC6qNYtwcXEI0KvyyITezEq8JxJRQppJx0VpBj46B6c
elxq+npmxL8JiUutX/lv9U2mlWWZnz8nIkizEzp+frGyINC8usdpUtWKTEWiTM5eHZ/Dt0HRbOuU
bumJ4rvDRZ+c8kSikZKCaUQOpNfnaTWaE1aVza5LJ5V/d/xf1eKPNmTJdVf6Q2KBJok6Bgf8ZnAl
nHfEETQPdfDcpjU7V9D2rAAOfcuSAIRTP4ymfgPB4v52TM4DwXfF3pP5UA6L7oNppQSr0d/NgeiJ
SOJ+x5n91pXDDNM2fsM23brxEr2FglprExM11B4sPay8L/lOZjJuhPmkz24nsf7iTK3TIjT0PJ0H
pCABQ4GKnlxBCygr2ce/10o6cIMloh2FDN8mIuCYcz2sFAuz1qIiB9/a4HhOBIY+8VLiZtlOSVHD
ZOsYUHNpEjVEn94gOkgTw9BjTFC2bLihfPzncrd1WE8SQ4qWFp5cKnnlymVX73k/C1dUeyJGAxtT
rZ/+XtxtUcOgYKPZpTh2wyf3zGV26YaExBeoSeLKPsP5Gdn1F9+4p9X1PrcyvDfRmpcrLMxqcPxQ
Lh9/MMszE7dlh3G0lO0xrrVXt7b7su0hIWphr8Jk7vkx5EDXK1DALbzCuI8Wz18LjtIXdQ+dgGLl
czFiSb4by3BSg/tjithvVK8vM2fC7YbpyXlWGHJCSYO1iEUST4SLbEUPUZXMkbiUjErSPIRW1Unz
+/xh0mPprXtKhhC3/tLu/GD3CYIkLMHsnwKQX8lUmacakL0qLcKDFZT7S5ra8VVTCbWAIMbidXGK
JDLpNcB87xgMa7QFHjKRDiO/i7kIAnP8+UQ5xMdCe9vW7vSC/wGIWKSna8kFcDmqr6T1J5b2YZQh
I6GB1C1OcYHEg62+VCsTLUVREy7T5b1Yylh3/tK0zpXsvxKatHYBKl5wfIgvX33YTJnf8uzifAcj
KGW0DfmHpN6Dn4QxF0xAJYQXTdvlUlG1K5BHvCvb2Ky1xUSaDxfESqaB98VpqAEDm2RTZOZLKhBI
Q23Rg1IP2qR/vukIGTDrxXdwyvL5H2NUAiz/y0+X5X/cdHTLPg6h3VxqutJXf5HSZruCaDZEPZLB
EhyIIPpXMkDBFE8s3kDSKE0N/9opZTk5vVjfIp2Dxkp/cyvvS24UZGjtHM7Ju1XTTKYs5PErpnsh
qNwXFYoCFRQglrni2TG+G+91N/A60yoR1rhgQgjLYf8TUjSePHXjxlZwIetoBSDE45+5jvNWHX2a
NlS2AhJzv/tNnko7dq5AieW8QAdW6gJ9Rs6+wf1/12mw5CMiDscKCukoTZHA3ELD7fVtGjR0EQw0
DVTIYtF+JCXoGGmHUp/L5YlHqKfR/+bSLKzlOlBM2Q0ytT/IaREmmdc794Dx59g5EPh4rNoQ+4R+
DVLLyYnC1Mahft7TmG3IF9LagFqmTPTw3ZWYIf/I+PfJ3CBcUm4eF9vlhTfNIn4u8bxVoKNPE+AC
cRrHd6jEvTqgXghU+P1szBQdBRhxnijN60KvFUHn3Mi6pqyatOmncDPsqpPhskC/l1dkBfFRn8TI
nnidCxKbnHUexPwccti6cpOOhYrmNq/nzvCRPHhry9DCS2hA3g1Z9LuVDDuw2Gm8w1yksb0kr4Ph
e1kuURVPhYbdHoVYacO9q1aSIO/aEw6U5xnAOAK6NNkBh4Y6vK0K05i2FvfNRteIAFzJBEO1Eir/
GSAKnUAclQonPDJEteRgsWhxrA85qUT0p93pdtbZl2NTRAhRze165uj+yVACmOMJAPzwq2gQLLBu
sDfPr4ZoOJizQMY0E7PfF8diU4v49zenU0VuOaTr4Z4bp4MkTuchBlVIRPhpyj3LoX/DFitvhzC9
c8ShMgd6lq4d5+HkBmumWzgy0gT2qiKX42LyY5M97EupQle+aG0Kf0i8CavR4X3GOZw7WhmB2/mQ
YsiDQV+m25D9ovhKdfLUBa1QPmRI3UrIBVZxadTjcB/dC7DARWmXPPv6hwLfMRzc1OUkntOFbXfd
CKipBZUzmAV8ZSg7SboxCqah4o20bQJbTxjWjAU6m7EA/VKfBtdPEmNpqlrfAhobuRR6EGT6MdLE
h2MKvE/TbZy2hu8O7CidJ2NvTnoZ4YLOBv52ex2R0b74E16PTS2gQX8MRT0PXehDkvzZIVrBF9Lx
NVoLN+Fd0Mi0DFlMApd9BDijyCG6Kgzh5WGXKxiNAWWBM6TnT3wQKbZWq2w8Oru7BUJL/tpnSIPD
LcCcpYXd9m3RGpa41tcqbDPiaTRc0BDOeTzgJXrD04BlKATqwLP3UqCMpzRtjMwAQGWr3sI/LqYI
yxbEI4I1j1MH1C1zb+Ec8O7McMPkkFpk/VDSqzY+JrC8105fFVOoU41P/iwjXp8lSYZ5L0OOPRWO
veF+1tCuuthsopzb/3jS0MgLppGE98r9NKzFSQAdOSYksivAManooMVXlOhtOXdZEXvcKHwsKEyE
ji7pQPhG2ArcRwQLI+rRc5pbXQryZIAqt3bAwS0XMkwINTXRiTohcYBPAs7E+d5jj8lsYDwTLjeV
kWUMnNzjnvWYcgz68oV1XuOD0xnRObtiIyETTy1y7zB0jlZEHEb478zBRjGE/OkVE2GVyemP3a6F
SXPPeAtZ5UXf/PCpubUPfIH1MYJK9KqmC5wPBbjaB1oT5N1IQ5iiCDA44ynErj+dytRb7HLR7SMX
bgxDctZMjAJX4Iv5CYFlcEk5WfJXlQoJz5XEUcw+Ly78NxWVSpoIWSEdhnGlDOwfPAI7vsbIQDIV
Buauu6W3+iTheJXgKA1kvttPDnz1azu5fpHcq90+rf1f271GIRH+c57iXE2/Ry4jqXIHrFc04Jjl
1Li0ow5dV+zCxwVxFBWMVYrrypeFaGYmbjhRx+JLDjnXFzMug+P01AN27jRj2sgrbZHsjYsFWsRK
rQwcyM2l4aXI3qXewxD9FU1aOffa3xCfdxmWt5ElHLeJMXVAl824ir5rRi4tyxChngidFDgnZbf2
vJDdrDVRIHXIdwRbmcKmaRZLosUT9iLupP/FnPDh5KBei3gvsrrzLycidNLq4CapEfEw8QzCnPfr
svef0S8y4V5ylwY8PR05bQ+dY4z4LkFI25EFE+RHOWV02+eDxhInTh2o1/AFqidaroKWRaEDStj6
LUH0w5WIDDdgNAKJ72cgd6SQMz7D+NmUnRwmufn4w/jotu9xX249R3/BhhzAvRnwM0O9FOz3X+Pc
PWSgE98zr/nRPb0SFdUqyCQt4My23OPq8FwNpqCMZ1fhkBMw7grsChF64is35iDiGVhO3HUI30cv
4bTDdz58adGmhl5NKWGO1+zL7mZbtKf7C9CSQROq161WPPu6RuzBAay6EXas8GQ88xNHkSXvdEGy
+jTd7lB6Uq3nPKsmPfoTixPWaSiNLDmLkaSeZ/sUh6CAjif1FcTsVonQFTOEGM2vkQMdO4kQpuRp
EicPIy0U1saw8gDiJAX9IhneJKcF2S03lgyB7byhcdglp2dD7ppU9BogAfTz9NqkOGqF8QGVC14T
CdaQSys16n1xQV4nuLy/zwe6iiiC0eJwa5CMn/VPiFbFSH7xY095PwnEIzQng7LXznC/Gs51Zmuc
HD2sLHgncgxfVs/x8TtKf1FN7AOJ7+JorAYTgZLhBYGdjoYnretZtG3HW93JJMdQcGF9fKCioAVR
IlKQ2tqL0WWwn7HRWSHUw7Cg57uY4eiexbITG8cuJ78V5/A3X0/+/hOTv8FOmCCbTvXNZGCiB6x2
7UkIvNyUVycoXyrd+wf+0j6O1aqRFpjFPX1qVscTWQTkEFwGGA54ps1/0LXiJn8RsGuciYzcl+Tz
yCUorWsnv+rnBN099CeZMxiPvNk6cBcpTOlIjY9bllRZryN6vmqqgsAwkS+mEilI8UU/lo3wcB9w
Je3Nb7NxZJIVz1Wmc9NdOpxDFoFt5MUlfO/k+2+o9+qSVFa7bqRN+Fk9NCPtH65FZkNmuB+DYwEG
8xJ0Jh4NFddmqWBccPoXip4uISopOk3Zw7mc2VcheYhx1ntnMgH24nBycLRWlcYKAUbG35+7FbMU
v0t5sHvhEdlbccT0mCCyaVm3b/cWs69XYnhm1gfQiDofgUC3nlqmfBJuyetUwK0DqUspUPpu+IMF
ntMeRHWfBAp0qVe/fxqz5RD1Kq8GoBEH83S630WEelQIpLNVmWAQjFcu99qJPrNXfg5djo5UCvMY
AsVtMpf0q5qkPRN5ya6rpdMAAEQt9TLKvl2jBgoDwVXKBL6tPPSMBLWxbCDJ+r3CIVqlBmeuAvUr
PgehLaMWrAgVMcQPxKQaFymKTZCDYJRnpRakaZauj0C+XBQYnMZJ02NSbR+QqL6rQ48ZIg041c3M
Wfupvln+T7XkAfVEg7MUdWSCxLF5PLfpRN3LxdkP3oxF0JFHzLLa7njhjHW56g/kGp4ELdIRWhFc
DkqXGzXmcI3hAkHrc5EukJznWg7ej/o8UiymAEw1m7IcOZazBwQTxt9esyZK3My+kZJySJzHE5Dg
DRlF72Rfun1UICGOWzexSD1MelwfUmRCDhff0J3GuabkeTsE7giNyOs6YUiHiUXXL1qFZN1QkvuC
ANGmrOyeDRze3EPKJv84LCVe8pQRb2NsS8ASPzjILXssdglXs9Ve5obOx/wr9x1YzGGaCOLYyoG5
93FpX53pCX3SCHI1CsvTuJGOlNZkW0c0pO6tpW5SRKyigCYODWFbC6H2x+IIteHmp+YZbuwtxEdB
Yo4m6aw99KjNUz7tnH0Gufk+Pdx5z5ebe6HLBl3ee0W9ARosqXvW/zVFn+1NvzlL40Vq+4Sgv+IA
+vZEpwLtKq5Cg6sMKrBYT3sr9nloMkAcVBu+f77vchXodtMHws4HBYtbMXkFGTqRC9APZkASEvbz
uLQdV0cmg5N6aQ3XFG3ZNlDruRFc3UnTb98Dbx/wXXN66Kao7iZR2Te81jF/m2s+wj+0e7qRHBkJ
KeFt2zK5oGyXUr+/YEHFNOBoWNPM5yLTObxvyrHJuvtad1RYl8JA03M6cdrr3Xrf4gF2fVkwSnyF
I2pK/4lgJ3AxqdTzI3VyJ8Z2/o1peTx3KNYv/vpmfLqD1kjtMGmf5Sn7U3arCgUv3DPuoin11e3j
641apo2BvLnx7nGWzRId72YNZShkYM8Ksu4rjIyqUFYkc3DmIXEUqXmviZ5Ejxga/mfD4JaoY/gX
DODRTkdnaRHcxiI53wChI+1EdgVH4Och7V4wrFr21Cb4Alck0SMmA00cUrUKr/q5cjfIfnQxgci3
U7pKQBcDfHksubWb0YjD8H3hkvW3ew6z8dNPwkkn6uY184g5pF+L98xEZOPDAczbPB1vGXkmJsz3
4KnReIHxK/9tAm84gyZPWSg4QrdwqaIltekQF5Yt/SFT4qQWncqngLUB7kV2Lowa3nQJKc34azIX
rr695CgoM4yUQYsjzw80PbYxunnXCoc6/pO3JkawmD+SZ2+m3sOQSiX3ZfMO+JVGCj82mQou6lSG
xT30nFHhrqVTJDR3s2JFjo8F3zeSAx42w7gRCUtGolHAmLf0OsK4D4Ikf8lTrxtq+xZEJUctU9WV
1AaVNXdCZAekfaRoMs3mo7Mspffcf2gdhDtvKD+5YScPZ1SejMEkkPjFKP049w8pycMSlhSQG30a
/ul7YtHcxO4CeInokQM53DYmWwZrkL6fz+RLNBz73twpPvNCO3MgwZBkjBfBTFvEZtXOMHPS+cIM
Xt/nALOyPKOBdV3USG95Uzmukdv8/LaiBwm8e/+1aceWhuzlrcrMfzSwkrxfPZ4UTDO/eg1rmCZ7
UeTisgvlSCr+S0oC8kyLWLX64SGPdCgl6UfqL8W9i2ybftTXbXGLBANn4FzASyY8/XGBnFreooE1
hUIybYsUlWYa4pg6mdvIgkCg5Yv/BVZ0rsQiI1EIeLbnqjAo/FvYbawc6yghDzBVpKh9QXYiLnem
VMWkzeJm98XLhO3jCP3tdVrOoS0+FBspYab+CLfNvqYN1afcZvVJUCx1drunmqhlE9Kk/da1ui7V
byIAGKE1karuA/1wgJ8qPpcO92EG3fkFnYCjziMYft780t9xv+e3arbYEnUU+05beZrafLW9HndB
gGP+AryfTOkcrXI9jQDMoBHaLxVXkrsV1x5O26QX3kIrTGfQU/GxunB5VhoUbxL0y3VSfx66AV6f
psb1d/JEqiZoQ5lfnCzjwDl6Lt+hSnaBZxMD3j9+U5ck90JyQ5cVI03U7asVdk54N5LYv5GznJgO
WMl/hbZWojYJ5Al+xZS2KTsF5wVNu1nk6ORMQ0GFn0LBfngjW+lfRvCkUFgRSvOf4echAHTK27pJ
Mki6yOpaqaVKkN1MSN7d0ySJqzaEZGgBhnlXNSy+CdI5DYiV0aSzQI9vKPL6dPbDECMdxhjhLCqI
+bSuJhvxs/VOxoNTlYun+jIYWDJLnxrCbLZ3w/lDcg1cbP/gUjOPx7G4KfvshnBVHSS6Vgee4hUQ
W5Bxbu1gqnOm4O+P1xnidIBHLTNhRjGznmMeLw82SdyEcTt6p4l0c6Xcty1emJ6b4anbbozTaxPM
jM2i4l7quMadNan0ZlIDHJlFUEed3oxtQaWbJHM7cCQu+J9+cjVE3T/QSQ6Yokbd+wfeh7I8YhVA
14mWJdBu+sAVbAKtTGM0aGiFLjAZrxwlAPLEoNG6P6Pyn82mztORP5Vry2r4EU+YsDhzyZrswUW/
8AF5GUKv/Klq4bD0wUEQyFL/ZPfTpinKHZszNtHmCI9NVWzxFXRoBVf0vof0zCvxi/GnhT1rjxLT
EiYIrYXSaWX+bmh1Cjopp/+X+a6SzshERJ/P9j6aiG6vxkNEszS0d7qLR1u9rNTYNwXdfjsbxLg2
ZaU26ZnaKb8M8JPI8KqTEVjD+N8Ii+Z2VCPnQURL8ZO9w2jsBIesy/LSYLXoZ1NUUJ9v4ptkLQcL
q37gQ9DcLsagDIEAzStaopnlbGHGQSPBVp/1Hl6VFndCACRV2ueoUSVjPLNOTUOCstuYOLEVo3wj
3buOx14Z3U7QjSJZJaroa4/gkWsjVVSWBfd/kNpsWpN/AjGOXxhMlitNQBKipcKA5QhCheN5ijZW
dtHzn1cfB5iEm6yo6kvL+VoI99ZMpcwFWFCOjLzvBZC/rFCS52YD0aCS2/mYHsrCc6Mzt5klKHYF
eAfGkHPrJlEVG8E8aWLixC9rrnO64SXKu/6MmTBot/ZbKZkKEBQ1XisQP1uiSt/FuRTQqAK6JtxZ
RjjAIdRt2WJn13DWl4XkLHFVJXyB8kfHlgOKvx6jFvv3WcuLo7yheKzzMosWfsBKuMIeE0aqwN5i
xns01TDfMu59NibtuzjeN0MKiW4wP3CXieg1O/3NcTXbijvNRLscVh2dZmEyd+Yq8C9tjU00ziLG
izqfW/H0d7eGrq/h7SQdj9VWm9fC77uSiJSr5QX8dSAR6GzaJJR85huEp679j3Or2dotb1Zaqmgh
psUJ6NMxP+ALCYd0aleBzYcTbydmtClhNIR2rXK79yvIg9icQyNzt2FY0aS99/+xVtycHdNZ6GuH
Az1jeDqmhE1Bzb0Kf3eSInF0Bx7i60xOVYPkSxxhfdtKc6Ai71NLFXWDdmVSo8zM5yWpJNyzxgTS
AFhV8AWbxy9TZ7I0DSsw533cU4+OKmPJA9XyB27A1rwGxjLDqnXao307svlI7rf1ss1pONrGpTi1
tmmMU2UfMSdWcP8LtLIaVA7pY6EIaYMSx4vd1Sl4HH4hu7NB2pzTyA61pUm4ipvHjwVuNd3GySG5
DjLhRMRpTRUDj9YmmhdO08+51901U3obbCFapfDgGVoExNe00qH85SPNwasLa55ac5gYZBB0TodO
Ti7ZofNojnpZk8yNx4XmzXJLQHoGIIMYgfu0W6GWz+E89uDJotB0cuHtg7NuCLWk3XtSGVW4P96P
PILCfh7QmNrMJmMP1CoPHJqL06u7WIaOtRCSfblvM+8qLdFvAcsnapaDhZFwYLCT6/7FpmUHjBb3
pkTbH4iQGqwKniUPPdZ73IxWIhbUr3mvVfLyevelcZofu8xZvApelTrqb0WNM/Z9MDrGgopWpzt7
8f+G4V1RfpL9bXT5hf9/Ew7DCcOro609v1EtXppZ8MmA/802NOtkhYeSCEhYoFeP91FuXUA77NQX
m6bC15GZK+YGtHz1JJGz2HHkjFPsvlOLcFGlrqx/oEoXgQQKxGi08wDsfGriC+MEKjlLFYYieHQq
iPiz/TbWaEpqsbM7LMjdFBZNy5KISq8Ke8rp5IagkSE9uhk1JhO2/O+/oITc9YrkqaWNCGYw86CN
slK+Mi49AzoVyt0k608YW4aEZsh3Xfv3N+KAP9GXwUGlbfkk5jipRtRdTF68sx6tqNGf28nVqNBH
DShV4IgnKF6kkOAYcgdPSsiS2uJPD7qrcWdW6alJp61Z97IhNuGyIUdiVLCF9bJhiurNFtrfoSSa
TraQVgxThU7GMIh+0Cmn5uF8ljbflXT1GJTNYcAvkqRiWQzrsoCskvu8e0f5eNHy8zHq5q4c4bi7
R36CLFuTh6te31wxwwefSW5V/geDSRwUmGseHD9QdQmxykSjAXy4Mykoi7NAEJmrGi2J68DUCRfH
tc9/G5AqYMSCEL3m3VwqMEpeOYQPPcw9EXR3Gg/INiKa+qptVybiwJYAnoizXjxi7Qwfxa5uGsbA
9fDMz5jr7pcci69SqJuL7pjJEJAvPlTfrbdzhB2XKWT9RbZX2EE5z483vdersp9Q5QW8vb0eaDra
nLg5Y49eGVF8DFzTVLmPs33NR4jqYlla4pGe13wXusNHuMJcyUbTskJ8OhD7Be0nHUfXfEEsPrK3
TMqIivrEPhssRF2E6szDcXCyygfuAQ8XYw+NXp5s7TN8LkctPeWpjTa8Wv6dEf03lALDhiQshQyi
xuboKymfE8iMpdO6nLXw6s62JUQmWUtPD4q2vbkvINIuP2qUpxBHe/qTGIcO5dNw8WlCt2WTuTLp
a/3u9E8g5bFo28DIecPAy2IAHN9yXQ4ebmjIrjzuw9pvyiKE7U4au29aVhd6LP4rUKUABNmXwI0e
Gsx4Icg88EyhENOUAoaqMRypVCg6YxOIFZQ1ATqT/MpODMl9TvfjhKopurXMs5e6Zt8u1pVPev7f
E9u6bctQHa/W4GXV6db1XCWTMlJ3C6Bd6Ne/f8Uk4qYrUQAi7zfNV3mvxblii4sb7wJJCqVpWX2x
4w43ZKBIGP6uAy7Dtd35VD5WzAIj0TfQlOEb2niWy83Z9lsGnlyV57SPIcB6kCQnOeDOp3vJe2Ir
kGsG5VkS6kDZxfnHxzVdmsUhoVeZ4b2utJQFlaBScUybHwmVKGL84GiWoezRyhbe5aCrouBSN0WC
kpzfNzpP+DXpEw0X/SpYGsHgkU6iPf9MhcP6/yF+IblNeIqzSv3LA7Qj0lfH/6qchFJr+flv/6Mk
bVNdZy5KZ+M9jqGNjvJCiTaJdurIUe9HznVSjkG+AdAdgZp9m7E/RZOgrpIXyNrzeyu/MWLiStIm
yK8R/O2QGIcdk4pM1ip0hOKBTTC1BYQesHcZpnCQwcTP4f/wDojPSk/UEM11dE7BlHjZg+qMNwfB
x0iY11F4RsdWdA6jkszOvxYZbzLFJ+PwP9dmjKvWDReLZxFBC0xlrzK7rsvs7FOPnVzF1lGZT/68
AhzVngRrosZweZBHQeaRRJWG3+9s7Y/9acLgsPl/ccVf3YknLrVc4YzsVygQ8zdqaYD9VL/DhrLh
8UBizzZIGgrpfbj4h0pdxJkqeNESD3qafRkcz0rCZiJF7VMSMsnusnXXhrFjWJqTv4YM6xC/5G/Z
gNMj6SgcER2JGftSrBoaJrCj7bC+tHafQKBrQYA5H29zZ7GOcGgs2ZS31Rnj6G3H8szqPv5qu/kr
oWaRrTc2pm1GMTkJ414G2xS2rSBjwG7mfZAjVGSt+UMagZUaYG0hfOxZ80RFzL/oP/7Ui9gGVjDk
CA9e9F7PDYlv0EMFounmM5JBqMV2uuvsqpVPsM+isYfUWDnLZS0znMT1ZmBfQ9xRYknO0NHpfY76
xLaRndXK+hj2jSoXsGVbS6xxa3FzQWesY9BV/N+qzEUmAeslWsKx3ucVvGHMlLP8D6py/Djt7XhM
qauOUjO0SdJJoqCoEN4VA+nt1/XVHsKGrqygwFnx0y3EzYOaPVJEhycnKHOB5COlByhQFSgCZzBb
udfPQj0+1oFow4Fy8oW6liiumfRW8JuAXgIjtPPC+Up86GTUM9IWoqNcVDNwOa5doiJrLUtxQ7Yy
3ZpueqdjzpVXffo1GJ9L/wo0YS5VVF9wK5Eji4PubCES0MdNxyCVpGxgwZPINjizNcJCdh2PUv4B
mJWkU7mIHiArq1MGWJZu/mIRqIOq4Kaq1hNcFX/RjtKBRO3zqHOVuGjh/bjfV3VVuKhU1+iRq7xZ
Weqcx9/frfO+XktPKAhvQP6Bui9XGYZkIXUvcj5kflYdKHeBeX5F3GYdb8ykF0MfYv70G3RyMXVR
yMbGe7aoj8/e2aYxk74SvbVHyisIFIGb8zKkE3Is1R+SGnZB8eIpWNEq0V43scrfH31ztjqVYWMa
irsJsNi2tHfnOYXbK8BACRtrTUNnbnntVJpyklMNG3P2v4M1keEKhDl1DYzO4wllwyVmHtlFhNvK
yrkAqiJi3wWXzJ+Hb/EZqCr9SduNTt5Z+iIphoRjfT2nJd6Ic4hF1thwAsJpk2OIccbikuNcwYpg
XD9Bx0EcDbJQfUlGk/wiH8DSAVKMMNsxriuN+vBEz9wySJHe6Cxo8b5vRmkGpeBSbT4JZvo8Sih4
/WPFNOZonOil4T/Fnd50sDJd8D3HsyJL0clNWP7fy8bJ8oHUfB0vW/tkqLhIp7upDL7Ep/NOvAlp
NA5ix8H5l5OwL56rzkQ2iKSO7sRW11taUFeA39CYu/Q1UFMLYVP7eGyoN5a0jbYgaMgWi3RTwaAi
sBhoNsewl+dQzkgMI7Pbk4WWUmNv1wCaxja9BjKXbqtGYelJnpGYTDIBil66iK7xg8n3JSUDsTy3
iFSx0WHaTOdCY8PaQRY63yhszK8lnfU3vyg0LJ2kZNaClmKDLEAuUgGaJnIKq/CyQgFje8bJiybg
Kq6+yRBXb5dSr96BpmNn6Gg8hD3Qtg4ls9QhlyiMG5rkV46rLg7nAHSOOfwhraF5rhaPrJpDIrlf
KmZCdOubhoxf3MpZdmDSEKf1V7gVHVYZdDs4ZiBkPyZiWeHBNHCxY0Y+Jx7bYoF961Y5pQnP0RAQ
gdjqvBCz6IJUDkcWgzhvqFUPTeAASWZ5rnFRT6hHrtUhd7C0U82JWDJRKrqF+imsUYTF3A4uLU7T
5ggmWLbPW3NIQCRuCyHGrYNy/fiQT2lAKIU8j27NFWU6Ftd7eCnRWwD78cc0S51sE/y+xJAQGKyD
I6QyQQ/l85Q1CEh+JU8Vy+hHom2VH53Uw/uOw3QSCH4LmU4Qgy1I+jSUAHbB0UH6TaWGsekLc2Di
F/L8AkVUTO7UFdaG/U9MVrYrLZxBUSE/Lo4XqR0uKxHmtD+zy7S8q3ePh8CaPQys1XRg3iijo9Rs
aTOEopf49/zs1vg1fhDjDVA1rNnV4ncEkEoX+DS+Iuw1wHDBoW43w6pizhOCmIGngNi9D3120rzU
oGZ4yR79ijrfOsIIexfYHCldhxSp3cE6nhpJ2J7csrJ7g+gaJm62QHBNqv0ZpZGaXYeLk/OKdE9D
Yld1/2cIlE16QTNnG/Iz83xNvF/7pYrX5UT8sT6TofUnZsJjhRhvYqlPXZh2kLLzqvQEe2koWPVE
sG12QS1oRShsntzcLWl+HUEPgkKdPf7EjsU/9P0fITUJW+E+7u2Dz64FA4o7mQwypPq3SG9KaxJD
mVOqzJHHMC8VK0I7+Bn9eRaRBBmGlyo4L83t9MfDNuedJ0NyiiMOASno7ozX5s4biVoZyZ/8BQ8L
wMAaFTMmMxF7Bqg5Tc/PVVpi9gGxbAMetEDA9M7Gktz5L9WNc1vzsEScGxD9UO/4G6COBYLM+azp
Ax29/jnOx/Qgn6T8VC5+F3ehI9ULdfA4YknSV5oNG15dVWlF1M/8h/TBf5EF/swA7ZOjrk+oSy+U
Bzowjr3aKvu9lvccCH+kggiNSu/Hv6Bw/PW8c2yHS4zSLpJKzk2ulhXulWfs6gVWmiNETkwnK9Hc
QGy2TV3RrwNZ/TnXOU7t5M1pe5drZrw1aUzU0x5JZIMXQHq6nRV0fyOV+bSVLGth5t4aBjRjA5x6
sL0SDVuCGfDhxCqbXTaIgVXVTsDrwUPEOgqw07CsRdE3aXEjRAph0ixdDayhqCHUj1VX1z5mb5yc
lIxcu4QRdkfHGpD57oZt5bbpDbkbd3m6Z9B+YzLcjiifoqjBnmFb10T9T+4dA4Bn1CWMsVrQO+75
YhCsMtShhZjz1MI52FPERAA/SP3FjfaCSNBvlkCkbXcEEqh12PzyNJJAMIZBmIyGIGwD01XK+dRL
x2kr5t+Wub7OI08ptKpEQY4px+L0rF3u9Vo40iHLvufebDP7jBvYLpGlz4W6bbMVzNjtEVMK1LkE
8m11GZRqN8erx+Gy5315ZR/+AjkCwRuLx5500F63Aj4RIUh3tFbpDO/CykvRv387Oye2mfptZWoc
h0f7tIcVG/mWZMtHH6Il+xjyFaWN0qqyyKmmxfXmwYiLHfJJ3g9tXgjq9BBSP7OaNVquxg8mXqW/
A0vCxGLxHpWLwBhDjOrHKD0nDACP5MK86Bmh6FniLGLZIIjlGt4/DPt0a7Tsqjzjm+5HzUQ5i5o/
KPU44wt1DLeVFYBMNRiE9LG7L5tZ5U6FRhfH8aparrJcSHYhEYCCZkLKbcX/cSRZqOek5BkaDV4i
Kuk9o2W/crFITRMbDir8+zE/2pIIJrODBuvAzzM7d8icmM4o/zNsul6/BGXSd4pKOnvgYuKDQwe3
ptJ3ZUUMxpKLpcQcs5M42TLsPeH/HH/oWwswQLunQ22+mluvM9/0OYNmLl7VNHGf0Yu+2PtLS7rX
MPWcNb30vSfC/jXQllz0+xkcca0ZglmZ1HtIz0D+qxsauANiIsHWBr6LdtaMNrEM2BWaEu/YyPSK
wYF+47pOQUVz8tG/v50SeJGyZisLCk1XI9FISvaRWBUWOh/zNcN+hhJ0fiyjAoFYxEXVkNWbCyie
tVAh4qxV31obmWJw5pdoHyFz0f+M+w/F7E9XNu0Msg1CJxZyMITASINVIzR5CjmiQc3AMRzIcZSW
kJg4Oqs1iXnVnz2ty6pEZ4XmbQpnqxf8wQEtdsZb5dhmBqY2GfZE1vZ/xLSpKAiMp81cUlxUtIvn
iUN0TqBnzAvy5VA3fpU1WQBWabKMIOHu0eox7tVJPW167qufaiSVp9bfi2pVDj6ANBVeAyx9OM3y
6MWyD+Ctp+jmIXH8j2BZbt4nSMhblVtU+h4VzxwP9DgTAKMxABrBbih/EbyrXxomNjmO7brh8XYz
SlXUdHVhBCa1Rhsbz+xKOj+SbFAnkAs0/WNkuOsQZtcjNshH7ms5LB5UIlGmlEPmqe+1Btvmg7Hm
ezFmP+F1NDgW7e2qcwGNv4d5wRVvAOwJsiGagguwcTZZfMbUFpVLC0jvcJd+0OtPxIHJiyt0YS8c
U++GiPTg7BVzDiEHXCU2W92XobTIKlfL2GzJl2YF3pqL100C6dIL/8dNzHqY1EOUUAQlKkYTxHnl
WelKtbr28ZOVwTq3iTwXHuMvQZbQSSpTvxmKwSmeoTKpTKv5UYNFBUcUm9Zm1AvzEqDtb2w7zsuX
xBOa8/CIFXN71nAn66XwEeTW01Y4dmPDdil1CMvFKDURPXZojMZJyjqy403luQnsprseCXtfjuHS
xUTnUCoungDtCMzXvA4cLqHNjqICedYRsGslvFtgff6JW7nsbMFx86Gtf1KmvBmLsZ5neLFjJx6a
tsE7YFps3190PkXsdDpiWjruaov+0oNW3wzibZj3SaEllTY+gtj9fhfYJhKlsaVQ+/5cJoiTXeba
9oMh7t1YfydUpu7lglmU38b9VkwTkhzwFrMjc1ZIjzmUGlznn54he31Ve3cQphYw7B7Q83+XE9U+
S0h21E/mqpKnwH+CHv4F+uX4CbTx3lIeO9CD86QYtrhRfughtg1VnNMZprHxwQThQNloAq+MtjfF
/T2Fh2E4btIZ3G+lqT2qEVzXVGA86g8byx5FanIUdQehknorNl1H1SOoiRWe8Ld+cx72cNwXLkgn
0n8KeFgw2TR7YTlfYKHgHtxBc8Z8eOuqsGSry7ntFoyC/bPNM1COJTg+l6G3P7anerH269Gc+sfP
78//4ozvmV88QFcAxZPYE1XpTenAfuF91U7gtIOmXD+dNjotMqk3bvSbR74e2PQTbWfEtDYC6+lM
dHCLM2Plx7vAZ8UdbjF0MucWca0kiluD/p/gskmPnZ9GJ6GagkNEhigNwHQoh29QbbYcIkpDxgZw
xVYC86G76rfHOjMd20+TbMfvOBTQupFUTkGuZsHh89EiUZeEFDysLFCvPsh7LiDr+Wf2+ab+AVj9
5sSxcHN+YjnOJLCAL3klIEkA2FEciNt/O3dheuSg205P0uv8xD5kucMR+ucEgyusCRViJa1PVi1M
8OqZ+OMtqbhfWs7OrV44an2zqFqCgz2YIDBH4JthARLpQnWOa6zSCeRZghaR53dsubWQkEOzlmoH
gJVb2BnTsHdjJ1rKyQmYgIGZWxHjYVU4Oa0fpv+A0yl4mHZDEwUEuHn/C3GWIwtKYvCIYjE8c5X0
ABtM7U2KpjEq5X1CunwE+DQ5nB+gAC+fEv8fpCIJl8OEcCU8okVQtKW1GQghd44bF4OGgDcqDWW+
JkFiNCzUAHDYchU66LdPwr/Efa1759UvIQz5Q1E5uYMpjErBJgMI+irm40eGcbpbAtlL8sU+q8oA
6EPineEY76IbjU/F7ICqAl45GUGhHiLPfseBxq2Ffo7Vs2+7r8SrlvFs4r+KCZp5W4PAfRrIEkpW
s0f7D6/TwHqwRJ/Ejs9Qu/ciX14O24r5BB+SOxDaoGrfH/y8sC6caLTRDTi+a/vbCR1ZSZzBHSW2
0SCJHGwIQQo4UWs9reZWr2AcR39XO9elUt0+1NORzK3zZK9m/Yq1iuRNumwVZcKpPrdorO4VKhdh
up+DxY0QaYcigIp0qlwaaGi9iLH7s18+Qcd+iZqxMzfm/TyVWJzTOyds5t8wfCVRddi3J8gQYYUW
AclEmcCKsIE9xlgN4/Rk7lxioB8vCUIjNyU5Ihv3Qk3cFMp16if/OvAJwBeRboC0k4NUt2pEiKMS
GeMoXh1u+pJ3PEgU1YhiItIMlPq2R0fWlCy8aC7RHdEX6L8QGxS6PH+C8MuF/q5jJxsQtDW8RD9B
BtWrzO+8cWG3E/PHGH69ZQ/DDktgvtAuDVSQRWHVcVlWSQTDH5hy+aTvwlvhRFtGDbJiH5QXVW3F
sePPc1bLlHwKb9S+NitS59cjUNTWdq1rP4oQX6JUCn/Qgu2i3WWAyzxbIECfy08/qprVdong4wXZ
omhWiZlPx6gxeGn3A8OExD1YNhJkrxjnlLwRUrZy2eOIMcEAz+7nEWzGQUkaoYlTPwj142r8ykAK
f8VYne6GnaAISUGYxpvCu3wenkhm40boXusufjiYcjyAdx1g2u7vBTMgnPmdh4mA5oEYzjKHrrUt
pW5k2NlpUhbePyhK3Ye8O/RBlAf2Y2e8eLJmY7uELtIsZZ6E391ckKbBe2/UcNwoO5/jCqMkqlis
gpeqlT4ryGqo0mBnEwU3F44ADQP7qIwTTobRN1a3qx32O7XUWugA1i+CuTSQkCrVWrS7nRTrjc/b
jECrdilkDK9erit0TpFJRzM+Ndrieb1SMuo5KqQJfPp/LB1hrm5NIzjgjQ3KL7Gd+MiQdUW2V7x5
SeRHQ16UWncWx7J879afuwqC+lBsd82APOkrnZh7HdD/Q2Oadqhzi0PJ3s67ax6VvR6QiQ+sjiJX
IbYlWWYOWYne1BEdjjr7cZUo3hOOfEHGNUA/ZwB1Y9E0Yy9qVrnmTgfCP+waJCp5saIcxYDKOfFx
WAqDrCCupJCQipZlGmGrRDJmfcHwE3Vt/txxzOUHI0r3kD2H3GJ4mRoqZkMrt8j4FUsM1zyST3G3
bvJ/yOdW7fTADsewVcSd8vovWTmbXyt6nWWaSOqFOVbch1rBi2rL08SjgdTbSy/buH/VQmmdrhIq
wHsxbz1aHs+PozNF14r8SH4+9/v7CkDNqv1uxCvWONXk0krdRzhIZy1tSjTaiBcBMQcSWd6qUpXZ
8pGeoh+Q0QC5uZx1g62PHJzbT+bhkN0STTwTli3qpvJdVgySTJEKFkE5pXXGI2sQ3bzQI/TnvOLq
2EkWwVbW5P9N9rNfKvje7U7Pi9fVay/aTqp95Ym+0tIUTw1ba59d1FlURYRFNRBpcA55s+pz5X0P
cqFJgHDkzMDAFzQJ3pRJaa0sd6u1PyJtTfpDOVWQTGTOBJffKDso6t4wiGYsTtuZOaMxDnGDxOa7
jchfvd1eRC1ogDm67o/y/E7gKCo9uPOTaaRLpcNys18IBhooML0mVRen/HtHNgqwQwN37WH8Mqaa
0Fa38LpItB7TcQWrKzreOEaTEOFc8141aKsmg5S0eidckHBbfreuWecU0Bvi3V3BMjoFM76sjMV/
sJpO0iUZp2RJZqF83oEW0M/661+bZSlFFFVpY9mblYPsEGEjq+55NAUNLWWxvop++r81puSYMMK6
l8tFJwoXwUQUkmmY0zAD4XbLHQ8mNrM0hyuYbgLKKAisVhih7M6FbJGZi7pdzvd2OozUgLTpfSPZ
i24zMm2BGWmYJFDUY5R2/PEU/GisXsbB5kEtK4AVRnOo48CrB++3oxTolNiB6OXH1p8oq3e21bAE
Ye3qt0dQ0oABT0mVGdUmszKIhE0/xZXwFgptqluJRZuOLDR+zwIoHCrY0vTImjh0IrlEdbrKyElH
6ZVWRpgp2eTQ99wAd5QFPnEi6ek0s2w5q7/Dq9v1Aq7r0GHYnNqUWm+yA5W6IEWVrjVOhlLtIM6i
ibWWew/OW2SZYQtkDPHCYybcUS+z8Z9zpTmNgEcV9wzXohtLSrtrBg4TgHPfG2S1EcLwpqSjZ99R
F1De2b0lseQcxPGFzOmB02Z33nP1R6B+VcMWOj96sYkgBus5DsXHghJFZI4kf9QEO468kPB2bgfT
eVUqla9+MNXuLaH71w9Y6nLc5Y9UT7OHC72/pBRBaWsDkMheV09o0464zCOQOnsDGloFr/yjS7QP
6SiJ99D3wlP6S6rZGIOxzpP/o2faiPbXqkb9MUxWeXAS0ObwsvYuM+L7Vl1UEreB9sbNehR1D7n6
n2GhSC6dl4CclFGYMSwstthfVXchC/K8sHcxzWbg85nyB/N+axPMWmmFFPIMQmO4hHex+gkl0vXw
rupLXfTK9KVLJUn+6xLkBp6g8V8bGjgUXsDt2UhfKJTuy2huYMOjQpwOIYkgWcKu0wa4hZ1WdmXT
VdP1rqB3mZ5fMwUcEAIvW+L0tHSyK6gb+NDmVC4kNjuWNaOvjuZ/nkUX4A94Q+eSzDz2PDMN7siX
jafQCfgM8ZEO2tV0Q1kqZ8U5K5bD7z0kSaJyv3ORcVf00rVwsv/MZCop1zkdm+ngFAzGBgo002SU
cHSVGhtLdJMCuzNHIam/W/cJ0iBx1LXJyhfBPGK886aTbLO3rkIgWhjasnprJfWUZ0Irnw1xkOew
LKs86DP2p0utObjgQ/88jGV1FuFUHihX1WHkjdl9kBPIS9WWsZ1d4ppC0B8aLVrXMkOy21fTvFxj
EwmtyBa+CQqTpbxhmVhce0AhN+SsQdFpRP7iWFNJ9EqS9RarronTXl1gqWTOhMkXT+8JJozsK3d7
LTxapJKOqjqKXMHLzbyYFX4s3uhqQu8wQkTKVnkbUnMZ2U43E+xbX3+L3IzPddtXeAVl8YXFARDg
Vys0lU97oIlAwApO7O88tYIq49qs12M4CRHjrZAFWsheO0KYAzS33mVNK9zoXAlgZFzRLI2+fYEQ
71Kek1DIdBBwvGexiR0UpfAGp32D3dgWU1MLQilzEL+gCnRodLL7gMqqCXx+BgwX8R2KkfQYCOsM
cXLu5j2d4k0KNfhwK59scGdq7GhEUUx/8suR2fOsr9/Tg9BTdUHyYBK4+5jnc2Pl9yDDcnT+sLyM
JUeCLAIVd09kjs7x+S9fz2t5S3AG/CgDuTC10zre+ocCyquhT7Br98ZZ8sDn5lTQWF0p+DUc8xEK
JsJKDjskv86pUp5Vl6QIA0WEfwcWtugXDOvI33deWlPOVn6MzisHuqIDrWfh+2OMRQ1RhPdJVUy/
8cyN07+3OkYPbw402hmF8ZIxfNJHxtnHXwhwMfj7cYI8z+AHL846tAsp96mOXsaag8I2Ji3Hu+2j
K0ER8/t4/PGzyxehhUTQUfs9KG1Zyogvtj7eu8jHmLM5YdvWL40pDWB3dIKL6ElXcd5i5aSaH00A
x/Rqv9iz57eTs2kvIeQOi1zJyTCIdwVCKeo+xzeS3YmAEfxrRNWSnrJyoj03rjwCjzoVvNghsbfs
R4TR6aVromugY4qdjY2HqiFi/819O2JNU4ckiuDgoT/r5epv7/ESQmX1P44IkDy594CLy7ZrCkB4
gbeb4LvCgfcZGq/b6M/trT8HAwNPd+NfoAmh/aqL0y87S5yzvCMlsrUK145sF+M3wbK2spmUE9Bm
Q24OiDv732wEeu9kogvieBLIcwncAVGSL7N+2jgBNW+yM+znzK+AfMekmQyaKan+HqBYEC70PKir
XTa8qJvRw2YKtPDpjEe1Kw4GUI35aO0LY5Sf2FeORGS6HXkDJVeBVdFlnnUdOBD3tTmXp+Anx0ae
VJEHLjGZC5Nqp9Py7JSJQtQgxqrPWygQi7ifGpOoKX4MNEb/uxicRfjd1nTIQntjih5l6wO/gNCF
/9ZcHJaKGT1+12jYPlbZ6LwnAQfoUuPo39yFIGvlueeXkU9BS519o3/pmiRBrFqjureQ1Z5f9U5n
yANY6eJurHtrEIqnMaZdOjhIGggydazGQVcML/jZWf67yckJEhc44WQA/Z2vD5Rn0EnlEoH1MeJY
f9E9YreeYd79hW5lmJfS4fJ95TNUm+gEHp55WfXAEx25FD9KATW15GuI26+zGHV6op2KK/aXn/wR
9o3cPG9zZvG6aIbvTa8TBYEwR1PeBT+opzeLSLCCRXVO5KtQ8JdkHHYbkYwdmp4+ZyIwTakLwH/x
z3/W2l5tB1AljgS5yCRByc3zc3fSGPZXI4xVCghAOkcAp3Gqaihx3mW//o+VC337orfEJJCztFrt
h9p4TfiC+XnHetsYubSXdWxoEvcejahEc6P4FMqYGscsvkv9eBUyxp4nIlVnGY47EOoG1Xh7OZSF
1CreT7ySK1Tfd6VKd9nXC7YYzaI1cixb196ty1YI5q2CvM/6Iki2//U5VR/ZmGmh+vtaMRRv/a38
hHxOuFxghX8tSjgKZYS6Uuya0dn4tcr5U0AoITLhIXQyVSQGrP13H6rQLrAYm1ttovC4zzV+RlJc
GZIbOHaBtwJa1humiAzvuqJh5f5ypsJtC++WfokYbkbPwKXKSJCnD+GHXqxXCjfSx4bVq4o9aX6/
FZ41av99v9Z3dCXipFZ0XMYHDH3r7xowa+WRKSOKEs0RJdpJ7ECh4lH1UDBo0e3wMFyx8Hsg5HBj
RMPUX7WQnFsp3FLOX4gTinbgO8H726l0x53VKDfmYWfYNTFeozw9Rlkd3yIcmJPLKx2TbtGtAB2J
pAcrGOLUuUyH5d/euFAlS54s6maJ7T7My6kiCcjN4Ts27iscuwSFV9AYN+uwKmAbH2Jj1YYvrXok
kBwKYhaSLkHwGOpoKPHd7ZdG6B+Zdb17zHOL2FIVaLjmA/YTP+wzRXRYdwUHNeysF+6oGAmBe91Q
cCou7wWZdRPzcFLKrG8B9ciqfW22bdxL+B07P6PURdVyRdw+5khXUgrq6tnK+/sVCV4xmbyNg9g+
o1uZ80cD0rlcDd/GAE+I1IfxW3WNJJYRjAOGL1aUY//U7Q5qlH6o81oWGwH+DpneJlV1Lgb44J/n
lc3xred7eLqzSG+v04+g1/AommXHJcsTQCRosEf/lqAD/UU4q0yhibxOZOVaOUmhWYJCZQs6EHXO
HE3fzY0OWPxrBcfWbVgmF0sRRWBxMxxvVxf3MQu3YfYcCG+SVIVtc0nr9dXGnGGLkwqrBFpL9zZI
mFl1HOqSQV5S/Euvq7TX8aGMnHXWbAeVOvXdPZOkcAst1vOA7d6hlUy0qN2lljJIQYXwIwAOekMZ
5typ8w78hFeUAFsXhuc5XPBworboylaYr2L6nyhXc4qTteVCYlr0532M0EWRLYyQBnBNCxSfORHQ
cTpZLK9eiGzDEI4uy69jSrg5YeyMTM+oC/k6/nGhmDcmKLOngzd/8yjmB1PULeFMm74qMbYl1PIW
P4lBjUPkGUBL3i89i/wIVOIk/QQUvWdFa277taxRP5cikimiuQYN318i8x4aDWwb/DJWQlEOessZ
21ovIDMQeXpWGEhu0GKbGq7l15KLjqDbw5GkvVv1E94V1pn3/Q5t5eR2JsyPljF7I1FydxTS/UUz
4WCMmd9TEdgkqqATPe19TfBF13UUb7KXKT58L/nnzV5ZDC5ryuz1GXwLZ5hHQ4QdFlKRO+tKtJWr
JUdvksXhnQ+TtYzGaqb9FH5a+ZWEDrNTCxQ/KrCCwrH0gX49abILyNWQqq1s39ivGt0zmV9sT/dG
mUD9D3UFRstbR/WZi5lLlmTcaff+aEcmeY1ALX1g8mZY2sy3y9/k8n0OUzZ8lHxsMiu/hKdDWDTb
XJ8AeUht7+KLhAAJBfv9Aq2vK0WWebUtpata3gUIzTOwe1Wn8YNzvkGjUdUvhahkrsIEI1mt+JjC
gdAZ8yB9eouhnDDwd1E6tSvS3/bOHgCHeDo1rTqQnKsocNMYvZW2yRhlR0zFbfF/UnlzD4y4rVY0
XCD+EmOWRNapkicl5Oh4EBm4j0SH20bzir+Edkh4InQ2O1mdjpAICW/f1ZWlyRIqIfu+6UwkL1xI
8Wl4WXeQ0k09zXdG44Eiql/VVfoJY4nhh8W5fh9NnYguZfIjdy4pqK8WJ/MB0TEs8oYNxczUaPXU
hZ2cty7NXyzC/o/zva9mHqQVAHxac2HPkfIbC4n7AAICclbT5Y7Tzist6iSEnWQqAKOoHgFvuH5x
W91VcTmtiHHnRohsj2MxqHDTXBXuTMXnHkMhXkpMrh6nH0B7OX30vOr/WITCXpuYwCm+/bzAAkoy
SM76squKuLyN18InfKJQXL+4ugnMTlmTPrhdgKCy65xjU4XkEy8r7joViSUhRoBBgfrW8kEtVcVI
pc4yoYzdc6AbJc2y5M4q4+45o9CaZFQLh1lbNeWHCMjOCHD6dgKV4/KH0wunML38DUHRi9FFqKUa
36Xqm5ZQWLTK9il+eA5GrWL4Nx0aUlqbzdK2ySctIgYpGOkQSHSss0v1Jnhp2Y8yJRhkQP2ZS3LB
c57vJJoG8zihDf6mopiHGF2/mpH4HWSqIa7qfkwSRNG0Jg9ItmB+Or/GZid70FBKtxJqT819NDQA
AJgfatkUDq8giBKWElbNNjMhqTJa7RNjOSJua2a7KK3Ox2qgcTU4359y0Eon660EMdP4XR5UV0RY
aAzRzk2RiE3Fq8Lz34uImqBFRkJ9MYInfPcQsvJdr57rzjJ13pWyxyIVHETPfMsevr9q34Wh0Lqa
0Y8KR2nEXmHq7RbJB0k/kjjU/kniutPpQHFUyS71m3qnGBkRY2rRuV/2R7mgbpb8+Hforr0QGxuu
9h5oZ+GP7kiAyPv7m5kkK0FB9LUdcZTri1Te9e1ETYTyKPjAjs/7t+dRjo496yyT7JWfZr5Nv0t0
V09v+A2aPYsDstmZT+84BEyKvHaU9Aavtm+g2npuRu4pC/s4UkG9Lg5isvJCJxv1oydewh0Ufmdq
j/wpwZ3Uh9KDjc2aI6XaX5JRBB8B9whkMUVWNKc0YqzwZFuRjE/B8msAQkKNd7zCldsm7cXbr3EA
Do88fZU6eAxws4JQHfvn0hC1W1qO7+j2kIb6xw+2g7Hq/GGOkhqhZ8Ou8nqsoEpokTcxeQHqy8PD
yg4DGA0fAczQfYiF2CQHikmeOWBKM8g9HLQsoSZI2Vp16WGTjn5cwmeTx2FE48ji0CpH3LH89Ql5
gbOuOsHBDxpMnxzxPmqHiUE/yY65pc8l+ttPm4nZi8kaDsxfkF60pcBIUTxQLOhz3b0Sey+jpw5f
GFhABCwchfX/u7Odz6RY+QAhzKG2/PZYoTa3uPMTJ7EGwrivj/+hzjUqA3n9c8HqYxYxJyVXRI23
+TdxpFj/+cobLjIFlzMC6cVn01dTNFyeU7ElVFTy1rQrlXhSMnBWo2/wCFCtE3FsiH0cveVD06qm
XloZPkNE1bdWyriaEP4o0T2ormtnnVIlGechPvA4jo3diwcD47R/Kli2QCxIJBUcDezeDLd4KzS1
wtD+Raznlz0KSnVHhwI14zTJZ3+JbWcjG3caHVe3D9yZyd2KAGguT2109DHMQfOiVuz+3vWRP3d3
nBZKKDIZjR65Oj04gQ3oXrRWpsyMy7Uo8nnxbBkBycyQ6BhROoFJZ5vFVCoLMLrxOZYchsIoThxM
l/pZiebkmUJ10M1rIh2u3oLL+HKYLPe2T16iaAgY7G3O6fzHgERUqBo6zZ/HJeSXLwOxQkhIMDrC
siOL4GCsk10iQYHZH4sr5UoJl3la8HvDpHTq+r7uzHsAXAg+neHv58k6olHjSfFwKY6UuHsd0rla
dHBNGp33/7gEc4Q22TOIF3Jj5cxbVgRRBqvWXTFP3UPuU5lxWrGXLpm4QG9w/RxqaWIsLD+2ZBHz
tvp09+K6rF6omHEsTri+bw990bJV9atL8/a0mkbyx808EJ4qtzGWa/t20Zl2gEv9vQBEupl4zkSZ
Jq176w6ADUFuwWB9Dw0UbbovhwU848VM4zVjA7A7PzWfePHRgACTTgRTkS/3hQv3srsVmi+4UoOS
4Bse0r6o1cbbrVAprGR8Vq3DoEEv0vy4/beDRZ4tLkrVI6h0xKE6KdeBGZTzw2nOMpJAAeLMXab+
nXDTg1W+tNVc8KKXQRiJrwdzhh4m372W5ukD1GsvtpCITYR/1loL8r/6Nz7rOYRH8KZBp/LpbsEO
QdL/D25w358TA+lUwh+HYRgNy6FbPsQ/Q2nSMgoQQBFZnWBlPyovjZTb6jHFGvzEcU5/2EWZsszS
xWRCl4Nplww6V0HvoHIEaYWUwaEp5cuKichmeNqFLjzEexMelZ3gaVzEg6SmNfv0apS/DX2f0e28
XkHX9PFCbjeKrsjP+hVg4aTmGaJ0eC+CDzm6hq4qfQoyrbSxtep8DVldICqFuM+f28aEB1BfDKan
NsHXBHzCUbZb1y0SgU2/Bw92wKO6gCARgnszrZWKby4MVbmaGK6+OT+1YFODlLmrvMF/kpooynHG
s3n28dpXpjzjMP/kcYGFI9YPf9QA6iPSoF9iUCMXgSxaU5+Y1sH6N6LhTNefvCUE5owW6jRfLjHZ
jw9XyczeaTVuTA/tlb5zs5upIm/i19YWqLj5RdkrWQ4sGKze7J7dEts4s6Vu5yBMtLCWQXfZb78B
YbXDtrpFf7SW0o/CrUMK8GozBR2BWFf309L4afxZthJq8u5KqCiGMPAze8XUNbOO8KcV5N62PsEk
dJkcOlT3gP+0RkNiFA0GagL/ejqo1LCSlx3RERBhKw1ybUgEdt3XJLybEZfqVMXzCOme3OJnjrdu
7VBWCNGMvMHbC7OBMaw+RBevbMLiCBbkXk2bTY30ugp66vATi21bleFqGZ91WpxTyPkjpLyXZmWT
IIbW5vSkkha1sp2ZBXECA6QDAkSswmiHtDgKy5nshCPL/GwzIUXv1m5vDgcJZDA81w0LL3FVtCzQ
tFan7LT9HZSMxu5csLitew/LhaUQMzHdm+/kwMXQ69gqfRHwkCnwNjNtutL2R84HWMciQSkSP8m2
3G0Li0rUEEGE9/Mx56V23Lv6sjxBc3dFOOKSWM2IfRDbwTwCzlpa4i+BIMNcqkmWjhADsajKz5gQ
rBAejY5ls9/48pw5SiPTsr8w/DhNhVoeTbE8+7eIDnMUT6f3AWy16XkaXDPgM63HrGLwm05n2Oo3
DfpzymrYRxwp4/FWdqUBI2BHHRi8e3EOHWa76yhI7EAb1YgITUMO4HVAURRaHdfI2KDuslXylrll
2/uGqNTQ2PcVG+I+LyoYh7/PrMut3N7BGMZHm4Qg8QN6gDerWSYH7+98h3wj5J3ZAFfdvbvdDK4h
zn/KS6VfIqvrR8nB80ZYDVSB6JrQejZpFAkxO0k1DcwZ7lP2WrxE9vGoUBvUywhGHJ7AuXaqtFlv
2oy4OXReVaNH+Zl4CUbhvZsYZLb05EpHCBl+Rs3SIP3ikoDnKyIDZTzuDds8AOBX6THx8R0HGKVe
tdQeFAUSyg6qhsh3UuzHt4Kr69aX+SudZCQzXDeVZbbWpYdsrURzZKGCi1uVFT2+HPm/IeErAaBp
TQA58C/X0HymlngtcWRsc6e5F0MyxorhngvZWUipPxvAnbA7JogVt9WljmsfPkTmeA5qgErJnNqx
GlPgkYQDqkI0YnLJ63FCkJwVUsfrh/SMinPeOFl1r47q2M5FhSGS6S0u6JMImUjFZmsfu38uWJJF
GvOEdg/3OOTto+nDfKkkTYcGTgJ7kViIg+B+8VUeEIuS82gJUYIsRlQf3R/XMA/SdeUOHrnp8ihz
GfrYSc4i7DmSGHp5G3SrKv0uGmx4oqKh9sjuM+DOCygT/hf0ZGkIkZv0SXiVAUYXoiBY1sjGi34d
eNEqgtK1QDeDHrzO7pY0i1u5EtkizET1mESD5aG8JkjCkwTpbUa0ftuZ4L9epR7hrDAYLhbYn4rk
rgOG2pXGUyciuD7j/CGFlsb9UcTZhbDFTVrmShj9QU/boTW0yrxrhzUFir2qTIfs+9xjVfwtpGk4
rwIsviA+A01sPkbIv2xrnjqNASMzYtOOp5Wof992cIHO1O5M8/+O4u//n7k8gqiqLB8kHfKk7laD
U25tw1IY01IPUl0Vo4FbVZM/TDfgzMHobyHf4Y2MvsEftzD7EIGVBu0+w4QgbgK1aXu/t0UBt0ev
wEsEoOow+pI3pu1mLp8MlIapJnfKhH+JqJcAaFuvrf2PTDhiQWjlxOrg/9ED2lfsUlLb+mUxrrXw
I6zh25XrY/eACmJ/iTt98gDBUHFs3ofFkQ9DNQRJ1KTKWP5sJ9aemnLAmjXhknb9wwTJRdwqHQFc
PspW7FFwB8N0qNHG1mE7Wu06sxniR2SsbSYOeFXbBwef3lIuJC90V9cvYgKyoxNt83IplKiTbJQG
YOvjIYL5nSxJ3erM/4j9gQTw+oA9dXQBmlsfKL+dPvj16X+zYYLXDooAa2ocWH/OtOMsZSx32Dmu
MRTrJkAuwnejsnf7fiRkc6rT3EEpcun+2KiShrl4rsf42/bnXWNVCuzCK8FGchAtfPB4dhIl5VlK
ZmqAzalyfEIlmF8Hp8k0BXRbXj6PqxPD9AA//wgZ1VRCiDRxs3cWwRCE0dmmua1SuEEBnSpMGUGv
SX14W9LBFkGz0s/se3YsNvgxnxecoaId/a+G5bHZetx9Xpk1ZTLsCHq0MwPrprVqo8IF9ZkjXico
JXQfhZyJSy0u9kLegJCPrc5GyOrUYtaVEOTvunpqQIPxI/xXvnrYG3tUZkb4kCcV8pj4r4oQb/7h
H1TjrcjzpEtSlu7kRv7Tsg/qfI//aFfZhz5whMtWoRwfeC5JwqY5tGRgqJe6YowGK0eGIIhVHx/Q
Yk+a8Zlio7TFNgjfZGfR39hEop/DpG88Xape76lGWC0+nP9ZphRCs4Dzzz2cSOUn6KvFRUtLhuzL
FMv4EG9cktSdizwex6nLeQIvfV6mm0HdZiKW55G7wo1ZM36BxOAoZXGA+yI4qTrqM8tq4rmxqF1K
dhVkm9qjwT/qQJRm7rzfAuIT1tzRH3+ecumh9NN974cMr/cG5QAQFA4BuLcPhpAeZJuFeDloQdG1
5V1qRditgkHMOwOMUYLNTIWQ0LSW66PcmH5JshaJEN/tnLMrmX9ysCiLoO6tRz4gU4mpRZQ6fN6q
X7SM0qqLbbrOHpMtGMnovYp6FRgN8RUZjDi5GcUl9PaYsByvMS4G9ynnR1lKGzpTqNE/U5k+rehx
baWClwVqxAekdaBDTHm07EUtbS6fXUGZjSpi+18sZzn/I1O5Q6Dv97BAOOp/14fJ/vOLoIB4yaaa
90QByj2/Yy79l++8FqWxnO1u1cgeYHMNef/6V0kSURyDwU/R4rqz1O9GA9JSuIDCC08UtOJ+qdJe
F0eKah6+XLccL3Yw/pTlmc9e5z12ozDs6mGqBv+Q6ETzLTJ+vXhbluKdFbPchRNJd3dNCNnk8fwB
zjxIgW6Q8WpVXAbyTPmC8t5V58DJsZbHpdQL/Ch6Xs9ypDkZ3PP02t8BzrHLxTh+8qdW1TkgrIpa
bnYxElX8yuo03vfPfHRj4KP7Tk7HPxr20JqRAfo9IlyP3UB1hrCh6lR9BGogOCp/o+RzrEEuAFb0
bMiPKhAFY/+/hSLPUz4xcbOL/+4anCLuurDxz9IZ2qq3/rapJXOnhRaMtTN9zMRcxusWELNFXTk4
EGBWSywqXmthZ0kDc4YGRlHdZaUoWynfFUzOQfwFzyh3Cy3nH+se5oYuHcWkdbkJwGrbWHCLLK+4
50kwJRxezO7celkXUZoAPRtwZkjXgc7RAchNVYxwqtNskBzywsdsJy7XYN2COFiXpvIhV87myrvl
rdvS7FmELP3Vd5M+xspES5t5tSDW4k/gEGKNSJF9caUy1VYlsSvhnHmKPEXvohk4r3/RI6mRtadL
F2RofJfs5cCIBJBDMKvkJ+gdh4ABlkL8NiVD+An+b+GrAtEsHb15LiIqMyk6vXXfNv/YqaDnozeo
jEZ4tRJv677bZxZujcweym6L/E/65/FSxRUK9ED0ESRh3515NQt5sDt33CE4V1LlfKC2Gpl4rk58
i+i+wOJy7LxlO0DlJe1I1CxUOY4qRFIH1TJI5ffroGo4G30CUKgUgqIKomlJJkrNgjYtT36hf3mg
zi1Dc1sbQhoOx/wO2K3UM0YMlQtxcnAmNmoPhb2YwZqMsrq4yQWKNk/jiV8Yps5b2GCCw+vQneqH
ZqeQ0mC2i+4s3fWNpFnmz3fUzTOnqxEr2fhURxacshLIXLMNc+tjogAqpbOECKAH1KkmeW0C9cR4
XlnVbZsIC3FIJZ6+sEGtEIlaA3g8qcTRozyOzkKG9O4xkdgzixUcCCWtQXiT5XlKtTk0WhUtDhIG
yDp9PMylnK2twHwkb5dqs4RXQMSDoy91I1JDxzDhJ3ziLrNdSA2arhkwRZ3ESRYxSXX2dLrt1JZL
r/7H0gHFUJqnXZtnWq16VkeNy6Y+U+A4W+ujZZ3S8FNSLjGHItuucTmcc+sAiBo87fSzJp46Azc5
51/KAFK1do5tjz+OnwIgPRxgusGkItkMHZkN+pmK3GyU6fbuPUCSoqHbO6AgeTuRpZkooPXK3l+A
+B830ENAfc0xvagHXBnw1todYKJOXSfprmAveSFMFB8xbF7TbMnRxR9oQ8aos07YmgO8brknEdcf
jQbSNuawea3UMboTbMySJMp0uNn+VnKGHztsyfBCaC13k5di0DfmmI72RshneS1k/uBOevaqlATU
eKucxFTAudc8tnhHMf3G8h27z7medec6mwD4t7kWOzVfBSb3tLz8wIIvyNOw+RRWo+DGqIRXWbPF
ORII7qYiMNNVVCH9FtxEISy2jLfF0LHlMDcrGgn+v38DwJTdnmFP7f9WlBBEcIyUwFqkX1wf9bCk
Cpkm9vKUPWpTmAS4wMtWL1u6+e6fYPN8a5mPxZdYYxcActlyLfWKudWl3ik7CZuvwouZveRKIX5S
wrc0EerhcBCKkAQ9dnw4ltbw0CWCdnarTssUDTik9SPEUPGgvas+2rw2nKyo/G2HqSfLlQbuwPU6
R2duyNlonNNilpMY+D4sHZI+Jcwrnmy0Ls5EkUPK5RO4A09sjAyWSkRfE2naSg4Sk1xfTVkYcux9
IqJxbCTTl2ediPou317TrVqfTA3rbPLL76i9rS4ssHJma1VehyDuyc+17q7BLss9EZNWAz3HtI91
4J64x8LURIRskcnHn50cE7QlKMT28Hu9f8AUd+TwjktJFC44VcRcjdV9qAI9Bg7FGwvPuSEHAKI4
KlCSBkdzyt6QY/poX6bwk74Xp4xxpcDTSAP0NaQ/QzBJ9C5TeDaJ2+XSKtqW5eOLwHT8xr4k5LR+
ifRm/Kwzl7ZBZG6dQlza1JnLqljV82DxrlYhMIuUqU5zUy4Wu77THMgExbspW6JUQspdwbtcdXaO
IZB/ey8bGP0OmPZyJFxy+60Lsumb9mOIfpDZnhvjamtXJI/s7PHjO7ete4zADj4lyqs1CdSbKRAr
90x8SD3Yd10MolNXI11QLNLqMPoOgFEWbPJoRDwnNHidBl2ziVjL1tRMv6/mpSIoW0JOUVcokOFE
iuh+hAjNTF1tc38vXsds3N3pyPH5jVy2l55ZKkh32wKzczWMqamJh6Bqq2LiERHCVE484qiHtVma
VeSKRVMGk6Ng9jqkGCqIgbvpVsMs6pJhrknzfgQzZAT9Gl/+xmsm10s18CNX6W46YmrPft3d5zaQ
ah4sY8CL2sTkSKZ6ZyVnO3xOND0RA3e4e46Sj0BScWE+WM9pBTZKnltxzX66vU5+dQHBO+4/oKpt
Ii+TVjljyOtzTOYwIwOZ3jRZHsZvLNVYVJ3Xc4LJ85Geb2vUzis/9GYrOaPLjiow99QKg1Om66Mo
8njAM1Jki45zITwwZFliVSycVi2oZER57CHNWLJHEFieusVkqgzCAx4XyflG51ccipDh0vhnqZZl
nwHN4MZOA1nBXMPiAJ4mR0U/HApfE2TBJbKzfVTLvW3g940oh7nymkXiKSvR121zpOXQCmmLx3CJ
G81GXv1g8bqHrBIqghPEyq0mvG96V3Z9pELyF1EyU5qtZVu3c/CKsgKjLB77oMkO4iQIBzdKSY/D
AOdcYp76keIOjuV2gCQOHRgj1Z23DjMAJQRO4rJy7VgE7YSEYOJKtIdiPc/X2rpGMQhTZYsyBwNm
akpn67oZgLNrQun59PJEqrYxDX90fS8BKiU3xdWTjjp8WW7lxfDy1E1RdVGt+qcnL2hkMz+C0Uae
0RJvOr4Uxu272/gM7/M59KZadJSIoqoXuXM/Pq2Xo64XXTojf5Tnra6yJXkq2WRgHOVI30l8OiHK
yN4pU/vN1w8DeB7ZFuXVl2FVzWAyZFQDeoBw5yT2BQoLIFJhld18/yoHs2H7ydFgMjr0IGbT35/E
1F9iuVJYyPDYcY9Wi9pOAYCVEtrWoXCm1W9oF36INZO0IjieS4WQWOC5Cbv1UPTvcCGuF78uXlFo
XAiyzb/5pdjwKrKXuaxPCGubvM8Xypl8rkaePQhWh0FhQNqSiegyEnAw4OYRWY1noAlD2X0gF1Rk
KGzFyD4MW697eiDGijD92sgvP6YuM9v8riHflibGQ3QYtR1v6X+RguFrUc63EYCWe2NBRAqBsKsl
AHjQGjuA2o9qYGNukzOAlh+TxHtpbvGhNKLr8EjdVINKVYT0mpkGP0SeItxJ40DSlfEQL2Yo8xnF
fR6WwErcaH/uKu72ifVAz9vxdLYTlcr6nGIPhdrB5Ly9MeZ2Wl6+ncDOJ5DNiVl1S97psmcboMSD
zIlMqave4OauCYdJ+MlwiBz3gKtpdYwh2SfALYX7iVor8MGaJcxmSDsF3h5LRWZ/cXxM6zeALE+q
gQm7xiY3sum2JtQCnjP4Q4EOdtm0r7I6+0Syy0WAQln4WtBsMEqtSp01SBMi1sTTvXnj6F7JJYaj
X8AsuwpM2jmtMJgAyThvzj9w+iKg/zWzL1ld27HqIZ65yE50t7+74Spq4EEmyZQqzLojm2Njy01z
OHO/MGxSd/aFuyl3e4RxsJugIZwdjQ+5MmXlXCi4Yeq0wHuF04WA/1kGTIvlkkB4nsg+2J/0Urz2
xB6EgmJocz6yzEMDDoPTR7VSOozV4F5ispk/V+MxGoRMAGgcqdCeyoBmEo1h5Emq1U14l+6afUGR
Mo/MJ6mwdbCPqa+LVBjh9yjsqmCCj52dEytOiVHDbpD3YgD+3uVOLcMe22qN8kYlVMHRNxGoaY+N
nLvIXZ0WFLBn6L6tCjPy+VBy1enzPg/wHTsdYVLWS5bKOe+Vo8sbfLcVvVB69P+UsJuBEscMfWZB
SAw4PlQaRCj+i5gsNPq7mxJpmIPnM4C/bs34N0zFtMWyoLHPlACdaqwrcsYXs/qFcfO5dPJfBVUH
MGw/G0wVzJTyUjj/w4jDhrPUtRrkyUmotdftoVuYE5z7QzrALWaZWuaWzPtPO8NLUmlrkBVY0R/p
NpE7NSJoJg0ZlU76igljlJGkz8o7l+MPAMQvyFikpQlNBmXKF5eGx6MVDwtarZojLG4nMrbHYrbX
8Z2VMbJt5GvVsBeWkKJpM8980nbwqKHKTJh9UQbeFu1y8hgylMX/6uSkN4LG9dIL1i39Y8h5clHI
LmrFSeWYSSWati6mM6g6O13L8cpLKkf07XbwrFNt5A8MWidrtX6ck+KVnKr6VwaoboAKwYUq6Cn6
Qek1JQagp83jVYpnBNdPbGaaZ4RxzpypxSyaEQOnYW7vDSgsUm578NKAZeZkYPrMX+yDgM3wg1D5
KcpvbSI1nbXfBX6Djs0f/MV8msnMK+UpMe9U6Ij7YdXmWgRrF7QaTv0sRMxizJaoZaf2Km7JqHBx
UJhZ0R8ugpYNiZ6k6SofGZIYdSHhzEZliiR3h2oZ8an/xwWh+gG9QYLAQmryqqYJaKrpWuTUgG/L
21oPsf1ekvNyz5olykYSB686KhBcmPitcH1stX463Xj5dEbRPjlBfV/99XF/WQ4JU+3pCligJevy
u4MyMbl1hpsEzED/25WJSEIdMBExCMAopH2KscFF6rpBJH2DKWg3/c5MPFLE8Hu/xSw4B04jlAO+
Ekwu7eiMeNCuFfKgXcm6RJv470arDabvlnrOTPDW9Mi6U9185+I8TScO2ZKsbsq5QD6EvfeqAUkv
CSYC/CaMpUfn0ijJ1FdHomNVXK5gSrkplt5yiRC+SxF3JxhoguBTqRWGEvQYDtYKaMBFtWltH1bB
FYvnkbiwbw+bSNqleSPKDyMi0Wj0R5TQIrVI0WQijZfTObegrM9pOVfIbsVxsxlDDpB5BQpWHbXp
rnTloPBbuQxENZ1XHCKGwIanYT4s+Pwg0lI/hvjRswXE+oCXZ0fwHPomO8c/V9qmf4ec2N/OZl8i
IsiZQFzOe34Mlr0cXsIQylGB7nCkUGACH3SE7q0O/GoP4XzoIcv/CdsMbHSHp5x+/OSQ9A0ch8xl
ANwFkrc2b0nkcX1Irok4tgV+86ivNQcB8gNOFuUuUiReNHj1zw06N+avL1LZiGKBdvCyHAwFy7CF
HEf02sB3HlcaD0hb7qtEb/dFstXs2IegaOuq9NcKTyKdm49b0fGoeu9gqyjuqQXRoNFuj29M0Fpr
O6BoFToCfdLzyaeqcZKmgqKBzrpEkxtotjlJaSiLDA1XnyWNNSrvieO70SbApnIoSGKmYR3EJ6qb
p2AOBjc0teRcZXsS01Xk92GnfscAk/vFddAN92e52rPDQOwRyj6UY0xkmNcu7GGR1e1VJI0n4/zo
v3TAMbE+ehd/ID+ChvkatTGvKWdE2ByFtO/M8Sm+Wh4xuWSd5nSlOkqmi0pxZkqXufSV1Io+3l+F
UobQb7x4jireIqpL1ra2vBr30CN5OEHb1owWCioPVarkGtrSUCfPAfCmHbVEvAPECyvFrR6DMVxi
WRXkgE2xAk+e4m8UplKSkBp+1qxzR/Le3QXIDQkWJm2w0vDMzHv4EOD5PoEgvpCxGJsmOJbYT4wu
/8fhFBB0FfGAEM5r3ANchSnAq828WO7JcDamWrDHP/Mzfx9rf46Mwd13G8grQz/12KVrzB4+4eZO
yOk3qexSU2XKC0v+b21b3HdaUuWcOYO2kWE3+2b6GOZ2Lnn5G3QVZkuyt+q6hHsKviR+QW8z3qvj
zxicXyRCvwfTGX5+2XE8fHB+sjKRA+OtYKmcgqkeAuiWHFKW1LTCgTfvq5eBbs7R8OJw5FMgMLgR
hfvwlnhzVQEAJTf09ijgBZG9kswe4WF2W90bzJkVO03Mks8eYr7DWItU3PdR093R/lk1YM1o/k+h
4xsqb08o8CbDk15nFelNjemWuDKgyDtR2PxuKaPk/bzgDyjLO9FWPBsvBLVsSPWBJpe/dV932Dla
+aoaEo3tmPOGqkOGSoDpkPtNCHGPpiTU9Wq9NtwOwHM/OacrL1tv5CRXTqwpF+QqVG7k2lUGOFNF
v5yiwvVgUcgXzDjazjJ50EGkxxGmiLznGDYOHV5bL1DS7mRiJW3qsNHAw4pH5zl6jATGDZ+XR+zz
JP2naz7J5jHWRLSroKelYS+sX5Ifd/Rfm0HdgRSLssh2h/sdpio4kmcc7VNoxDA5607d8b0H9YTA
5o7h0r3WUPP1YlsH4cPy690Wp27VxeXsi/+oHKatOdmIWwsdFEzBHvfYH5Ro/Zd2RgKy8DNVq+hV
Lvg0i+fH7sTx3KhAYBeH527mwC0bmYNaRQtG6iNknzxdruMjn2yfm1dsERZKR55jFczPhkGO1Oog
migSuqhbEcJzgUlrzrHVBNGuVVipu1CCghJV5wDEz14xmy8RtaJLOUgqXuA8h53Xs8qWeTqRmJvX
8+Ij0v30tUzoPop4+u/+lSq2AUWiS90b4QfuET78BQyvw/ehl/JCDNi71SS5BHnivxbZ2VfUnEeX
ENZuwiUzf84r3hBvlrwBXlmjV5rwY9XyVp1Yli38qiHs7wYrw3y3oXNwdq2c4dAIM5JoMRYlwmM+
Ijhmx6nt9gOwm+cXIC4hOtpukFEOP6S4oNydcC5IhHiC7TN2DG/MWULNKQ/EzwfKSj01diLSfi8m
Cbf88Ydxfog30fMlDfjzPQbf8h7vuMnhLoY7rZtELHFvov29XljAB899AHEUU+YcDCs5TooTMi2A
6iQ7+5HG/yXbQai1UIeCam5ZMD+R1r9DYuEcSQnzdgIQBhkm4TMxbn1R95JePlI7Ei4AqSWyTG5W
yKscLocoppU3Vu2AcqQR5VjxBwJg93b+uNZ+QryJI2nuZeY9VjhGA0eaevfu8XIsVjVhKq4F2ceW
R5uCcAiTVcQRp5jY30jt33eow2DYVkHl3vUm/YXedF6/ZsnJyk/QMYbMPjVRnjKaIkvxVFog2Iah
dYvnlQ+ixI7xebqVP1DDean2W20T/Xq0oampmQo93b21EuvRNk/dq8rqoqpBjb/Q8axlonXe49Ty
6ZX5DNY3MS/xCH5vNKtAw7D0PsWRqakAOU0vnAFrFpbeCDmuqsO+LEIe09BCPLHuCUuCVNXraJGl
vZIhyM4cTZ4F/s8XrPphuBZhl/ncF7eFKOsAnxsvZJcrMcTEClW+B1jbmkyv5xstxqEx58x0uRl3
F+jRUZXziLvMT2ZCCgFZrnOWlghqjjEqsXkTPt741RkrlrYNjhYZo5gewPvb1nOzn2tjZJ58eSQe
iVzbTU2nlVvmQw/oo3kpZp08yV0fyUvWiK6vJ9/JqFfgosLVOOPgO1UXARMezsFvKzuvkueQk8dj
GEnDlWrnU46uZc7Utlwkn0CkOzct88Lz5FLtkpVFFVxTfIoumvxRuzv/rnewI3+ZBHedbMk12sb9
DCt89yiHfKrKv7hG7VK8L/XJz94xFUeK8vzaWVS4gv3HRaqKaIHWtGS447BZneyCTjx3cIcWQduh
1SqH85apcKD6u8v79/4+bH8rHzdHHMhpT6OsE335wBoHPDNyQ+gce5VFOlPf/mqOlyBxVqKxoh3I
rFygD5ZxnKDRemNRmkOPR2R1hlYUC15q2zcap74iC/RVLhhLZZkYmVfAveEiieAxO+sNm1IrWPsU
AcENxj7xL+qNC58baVIRnU363vBqfVIfqRqJKc4mw3s34+EJYzm89i2tzXepPSKrsuWL4f00x2SY
VXXO+GqTo5XWE0o32SlyDsErLMW6jhmlYz4vbtzltigkPEmCr77ihna1ZVh44le2DmMN6+/23rXW
IQkIPuWsBMui61odvfDrbCLMh1e2KUtaiKn8sCqGDtANkgtbAB0mw3Mu3L2pdxLxPphXswEPRnOQ
ldvGTYM1ypCYS59G5mtaEsqs8UV4RSZO8hn0fuocOcCy7RPmFEA7Jo7U8QsoyzWHwaKRI3Z+M8My
H4Aq4/dFQ2Cpa68SGSSrj95zHStHP0drd3NQqxhCtiMu7ky7RtfaerNP0ljB8edjkvyEo3eUNQAC
XpjOl+gOcVqKGUE30S7kr4QBlWI5wxfsl3l3wfzth+wZmiWUjr2m0tPfnP+T6aH23NKEXAG4DrxL
g0k/l//fG7GGbcSYWs6zYobvSuu8ojqZqnNFZZ3PYrEcgQ08CBnFgM1ThxHaXNCv6VpHgp5TML9o
3fjgbo8FLmJBYSN3OBmc8wJrq3Hu9ykdnChHLim4/jV2L9RT5/Jiroa1soktAuhpYDbrAdNRkEys
JNViwMvzwFIiZt2oLQILavZ/3UNW/jQe52RK44KMWFyqM5wlzr0yHZgJfobF7dV4XRaZdu8Su4Q8
MsS0QZpRrN+tvUwMw2uB9edKMObLWKbXGro7KgWt8LxPDfeSBhFisb/HLnb00ishW4jEIQalnNDI
GCNjGV8pLsHtKUbbiEp/bYMfWRqbr3lPiCOUoEtltu8IPY0M6k4fy+7CiEU0z9GxcR3OzyaMTArM
FSkhlfdKDI1wK4h89bKaa5ZC6mERQmGR4joLpsKBd8G9LT2DiBKmKld/5wsiMLuFJEkks7apybIy
zx/BOFcUqqVSGY/FJbVxtM2K+OCBSvWuom3qZx+Isv/Bp4PzM3Ic3iFHksZKopby10DP3KmONKEe
fp9Qu0mqdL9bYvUjcG28TUtjpPOZzXeEWzBRadQj3dtXB+G6tn0u/Q5Yb43T35UlE8eWfrjahrfU
z3SKRHLehAIbW5TlOfsWMyKakORv1ygxJgcqY7D+b0Ty8jXoCUqSQhd49yf28JgfHRMyX37OZDXD
3VNZ8cZ4lldjwsjuY3ghPRroaF/snO3nT/VlqK7XEZRr8699oftLDyzsuZoXk1S18N5rTLutG12Y
Ba53vlVwLqLsaudSQFeKzcmQLzlZbYpCMKpA5zNT7I78jXEprZyYcvdahXdJF/X6p0FfJMQQKB/o
OQNmNGN4yK6e/vuN014DUMaWJEeXXYLXBmi4wfPsDwcUhl5DUwtaiyhunt2OmNM+j5e5ADBIDUsj
scuJ2iHZmGyXRUsLNwnXrYlywW5LIFwV0DTpBOGlEOmaJD3XCUb3I/ztPe9KlqFehRz2/02lUB/3
qrOEq4jiRh7A/TfuE4D/GCkACKZjsad/7fnc0Ahk80wMzxAB4gpSC5xnbokwGa0SQvgP6YGScJP9
zSQXFzDd5rN9nfyxJXj64MXYrKlODNjU97cZoN5LvlnlmJWIz12dIda0KvJLiMBrxNBQq4IFsPkP
0j9+r71QF/g9SPfKWwNLtMwj3Yi5PJo+38nEZ3A2rz912gxsdwNxbdGS/EZBaLnpiMtCD6lqzFzM
E8HPlCU5tkvp2q/EnkwcIPwOWY2LaQviY8D45DbC9t8AzPQcSfdzHXmQQnkqKTo0/+/CNnBsMH+f
R7HvUf/ab74iTPypumpEGfnxe439yVD6aogM01MD+Z/saQe7DNjH3oxu76hHcJAipgvgLPU6H+xZ
PwgQuB0uO/RHuKSzgZ4CDe5qWBcHJXDqAS5QroaM8EruqDsTZchUyuhyG04kGgc8Y/c919SMowC5
9b4Yj0ZF/5CjgTAe6eKqBj+Kdu5CrcrDfxuMfYv1KFDxaW+1cVX0RxYJpHIRWtkMN+CXUL9r6o2m
aoyGPgF1ri7FL+7YKLASkuyLw7lZQvEDSwuqhESlLYI0LY5TJcUObloD/4RGmd+7Kf4U1mc6jSft
2+VehyhiT1BpOh52OGKwWVN3IVLJvBykvp0qAZOA0I/n4Sv5goygtrBiFQbnLYI9JqcOY/HTLemF
N3GTW0WFNRXHLnzKsp+VQt2RPR6oTcM1k7OCO7KnNFSI0JRdjK5RBmEvqKmeOAJQENPYra2A/5/Z
+R5RNtVBZqZeAzQADNG2U7kTroUZ1lrleiHEPLkq2W6EUl3m7h6UhdgwFRTVgMeSDDzNvh/c4X4T
s42n5s/mDDQ56CmkoriF2wBk2Bgi5ChVVUUV5/WkAi9hnWaF9VlTfKgjv1oWTr2OYHNHJIJ6sSXG
P8O+hY+DH1I7Z2Ev4uI4l8bnajfQotk1hWeWBBuR5HOKBxbu7S7hL3u2RLwJ5ZUlyXxVnSO+lMbr
c73NrOI2cD6ErOv0jjc/FtOHex/9kc40ebPxoI76kVBtjg3RcFPs8pp805hBs9aEUhrTzXFlsEf2
pIzQnCtZRRpyVZe5H/sdBHP5LibJW5D1w6vwIUfNiPnDyn1JV+zxbHTArSE7kD5bWqOkXmkb/5WM
Zk2/WE3F6wlGmK7Y3EIIuq9nESLzbRzBx0CeQINB7DQAvg49AD74ekTUqCEyOvJOpp4sFCME/myM
XEcELrU9AbSGlLVL7PVjlY1iQbcqD5vFj9c1GiZoaqo2qgC5cm+MTQUkgjZtDHEHSjutXVczn6OH
kGQAYWs3Nk/J9e5oD/tF56m+tUe/BqxOwUpU4XEjHdbnZLIGNfheN8nOAlTJhcQWYVJKS87szCHo
LxAuAtbh4BmRBJv5An+Q/brFzVbgAPR4m7R+zpndX6v1nZvYht8K3fob2qJv+RFiQuDw2ceXuU8e
0AD4ujLJ2NtYDazZg1tlTFvgrQUe+lqnel7ARE2THFvzD0U/FiV+5ryUYTuu3vKzM2MD1JNBKgiP
iMp11tNfPxVRDmzqpE6Xwmcdn/SebSz0mZ4lWphwhn6cQDt2iBNXBnP2JES8ILoY8c5H04+pVLq/
qvY3L3WotTMIARk9jkhpX8OfDSdtbYGb00T9X+gcbancYc0Gat6wJEAcY6uHiDwo0a+naM8LiarN
r6zmye0jUOUAaEOWQ8CAvJwJd8NzRtDWaEaS7fwkz2FrkMKeHSDnYucsFVDc7uSAD42hrTj/jji+
7mc+9aBAkml2aEbBb9x0Hp+ugjsdWyG398BlI4T2hokQ55zHcgdfqoM4phU0Tml39LFYyDqHQHW2
TZTiDHSgi8kF6v3h0Z0hxv+WyNCN+4wKs6bK6xPI7PRX0Hhysio0Iopupuz1Hm3LzcSypeTKWo1d
K1N7opA041LQiimeZuKseVYUZ92XhNBbaJ9MpYFZbIxYQwF65zs+oFrRUYHfqC4nE+Es77XjeS8R
VNKEMPCrRxGsswXtD0ZM1ATIjbZ+aW2Dwy8ZraC3DJ2iSCOvw3LZpTSfhuhJ1wh+5qxwR/zcZSjj
KBxb1Q+KrTo0rbKWhQmsndMByvSDKdMWOcOibN1+vYhfFNtgflMaUIRpTa0ZPymRcK57YVTcWbBQ
QR4G2MBM5BZ9we6c71iWNmzcpG4qghWzYVcLBrrcScFvG+ExzPXofmR770kKXQB+0OiOAGtt4NxR
R9/zAhjoovfHRWcWdtA+laU+gRUudnwiQuJc0TRYV/MKuCjbZCtF3V/AvbOS9bWmF/tKjALOhvrw
WEirTZwqwSG7U1neIJO2zaGTscufMKhrjpPA8crjo9nccTLuNRii/7X4D9CMv5DnFOM4vQnAcerc
j/EW3TFaIufRk4v22W4aY+JEjvdcuIz54A0TBPZwzjXJuiQJsq030b0byRJDyH0c4StMXSIiY1LA
gPRKGLA4LDd/tI+72vA0TSq3A9PRvFxxzhk/uZFoxiuWjaibLq2rIkIh83bFGxVpXl4L43sgK9L2
0ccmVGMv6PEPN5w4FXGvtrjjiEqq0fzDQcz2qA4pCgo2KliEc9JZxSLQVsW3JtWG3PXyA5/MrFfn
H98FAKm5uBTDaGU9FetpXuSDlqemWrswT8T1ouvL1+yndGJ8yV8/2i6XUjDC1ENSjzKzDLdJ9uCQ
w9TpldxYSDq3if4AyzdrvACgmXpdmkIZ4/5gRcTHIqzt6iqkcK6KwpP3qdEpm1qdOSnUucT+ruUX
gRro6WVtMQgnVcrwPMj73caTIVsD9eggQMILWHz1OzFZu2ibDfxgVpkYKq7Ms3+SWnSvyQmIcf7J
m9ZKq+ZkQLYZjd8haECaoaxZfvAj56mv6lV4PQ3/Aeh/mqZfDFmHd1EPjRlrNUTH2jj4Ku9JDprb
MHdFsJUjH1TDi1l37YFqNgm0+FI23V6w9dZM2IaccbAOqfioJIf4Sxt2iwQdXgBfC+egIMayAtQt
t+dHQrSFrxils6/N1cuPcDff4ZifAbAQwifyewQhXW0KnKmJEsndbL2ihpsxyQDOgQnfETYAn72o
yOXgkuk7adoJmJ+tyX+N5xTvcEWFR35NFC8dFGd3Gq4nTrJVhwrCXsGZVGvlyZ8bzrSfJRiSsu29
044EVvgKYccEwtEAMKmGkPOjTi3rLY4yx5Lzq00W6bxJtnviO02m0EVCKC12XgKLDRqP/FXR6YNN
1G5P8VfxkjHrTlH6Ule7AElQ/i2k9QHDjXEAh+6rcAhbD1Kq3rVXJHbCu2p7gQeLqObJYHiBgzIN
BEHnYNrLZ9crSKK2BeT6Ia9DjgLKBHaZ+MsjOLlsmhsoaFlmaXPGZlTSTQC3T2rPjwCS3H8u1NB4
Cj3hXB9TD4Uo6h959A1MPmPGFg/FlFT2PUBuRD4ObN582RY68EZYo/zDn29xPSG0uA4OsgwFX1U8
cOu6/1rLMLoBfMVMAKfzw94mcKDuZQydwPEjKa64VVesbRnklddGyjAPyLwETewtBXfg4GG0C5O8
CI6Z0C75CXJQzSAbQacqiJnftGc+H9tiXC5zZJuzaYkjOo0m0/dWQpQRaMJuQQCpMVN2cFlgyNOo
b2oV++WZa9ju4LK2jQdCa1CqCK612gHE9urjAzCXKRgszr3V8mXyoeRxME5W2Rd7XcToBU47YJjT
Em2MVR/edL5A/i1Iyj+7nd6NNLoMEfJvLZgNM18AIxFYS1yufMld3ANAPnhghnC9C2us/Icri3+x
BEeRpezlaiaDmfILG+4GK8dlYMph0llLFdg++pR9jLAdNr07Ibg7dQsbLjLX+zjd09B69SFuhXXL
m90fosO9GkbplGRYvBadg47nHgQ9ZQ130IjQgzzf0l9ZTXoodyzPUQgBpCvhWJxhL7Jg8bIFCMNC
ve/nk3UlwGqzMxpr28/0l8gAyf920rU1k3xM58Itxw+t4GSE/Efy8xQd5VGNE0Ghj94FNK54bTkV
Hm4bd6+ef+7iG4ZfWeHZJC//c76N2wgrzfFXTjMEnYbKEK1E1/RQLaQJ1a/aYuDxJtNCAopZccLc
mwqoXIJb+YHD/26iCIgc3URbwgbic1aAbjsQ88IE+wj0xLrheuNDVb5JED+m5A+NkxYZc4itYqBX
vubYYZOzfe130eg/Tav6OrNnUwK4vI20zZ66BtbZHxVeP1yekkE8X69mPbVLDQEX18lIL3wP5+zd
aiajLuvTYKu704STqjqL5c6KWHLjjKtdGgoBKqpyHkWaUDXpT2cKjA6xB/DMV5wU2n0z0JS2BBON
KYasDsw5smEQJTqq/A/1Pomaf5acvODTWIcEyDqH5oo1KF9ZVXuEdgAZdeKhQLLdHNhPGi+cloxO
FdcWcayFSfEsPqQv/ciZ9gkehWj2kX/zb7OyFRHhs+AKAuf6UlIF6ImVaUpBJxcDemhAty6Lks4U
X+Qno3+F1SxALdiQbouqg9yAAkQ7sy9bhOBW6nm71hJT+pLKt4xd4UL1fDiMkndDLpEDudZJBwPA
BvpaQ0PqIZ09OQLHQrLHkKpFvrpVNveV4elWbH5nNZ7xue4nhKf3nJNVgl78ugeSBTtLwOL7Yqw2
Pplez6qTEyRknu/ej8/m/biD8TSAcwz6QYN6+kiFbsGHDAuHZ0VPrG7RtQPbgd6TmMrWl3OcF+UU
fCVRcZCczJTc6/tVARBa1tANfLSB0NI7yJ6iE5Cvpu+liJKq6fwn3LnOXLy/yOQfwtsZ0KrikJWE
H01YpIKgcYc7+anFUr04pPuTClCILrcf/43JhRhAMf1fTeyVNHOk/zFCmJ6N8Co3uKhwSdXrfc2O
qJ1EmSeBxXMeGDuEqkx9mm5kIm+JA3tb9WrELKYyI0PIAvckd1ZB6xH8xaeur1ceJ1f3GSe+zDqY
olErpiISKt0RD8ZXvkhUXFR2o0uTidwjv9G6PJ9XfmqsQCFQd8JkiF91P3vaK60uWdBbk4nmIPue
ZA0NZ24jIIZcFaPqFTcPzY2mEmqHEMv+yjGGbNp8nsHADkAzOAO4knAjcvVWiaXPkCpn/QMuaX7p
KdJ7Z1V7Bms/84+y5TH1TyIK0F/TWBJtsD3WFJtrJ8sBnc8VYPv2YMjXyzSLz4TB0b7h4Tj31CiZ
TwfH6rTDQR3ZPisFYBp6I9UdzS0yMJQE9yvRPEbUeUn9lvkTesiYE9iyg2G+cwIYr1sTIfUsw4dZ
NTd1Gv6qAlX36hGrPuxCIPu4aeQE+dxvmLxmWTWkej/0T6uviLw8q5UOFJtexUttGGsSSae5qGwY
UsSypDai3TXyWzgxeMkElnKfqHn7Ei7nIIv5yo+SxOMS0BYOd5oxtNCty5qH6YBTAcw7RvxsVCwt
vJm2FR1pzot68BeLgEMjtlDHWcC1uC9XCn0Bt/yciVZsO837Nc6+5Q17hZfpgKeqQPSF2A3sAhDj
EDuTqVONDPuLvQXqJw5xVLYW1ZMY3/dm5tU0YxptfOAPNAJSZURVVmXXTM8M4W++5SurByh3o/di
uxcvsC3io6uU+eyVWHxzCyhapRBPVNqNi18fn0jNMu6S1hAn37h99mV7NhJt/iOLdGcs/Ew8uFWU
XcYWi1Dmf8dCsby8scLHLaU+5qYwad5Fu5ZMfLawHNO4BrKYHZDfkBtebxgvr4pz1I1n+LOwB4el
sPmlEtnnpauMkLESNlMpwWf/yEQ+muQmbQT9leO3VHv3XV/kQ49KigzxEZn2vNjo7crtZnrv4k6g
sA/cWj9RZRZl8CUH9B3PCHqfArGu59TqgpVIFtm8b2mgBoUnFSiSIWAPTQryF6cT/mkonPd5cu8e
R9XOs28YfVh1KLEfeKcrD6GRH/FRAf1RZmHj37gijHoR5P2YLujsfQi50h8/Vc/JNQ88EZZR1eJk
01AywmooeRFPPax07ttLv5X9KGZhidzvY+C+tdflQarJIZYN6D/KJLhY5xs07+JOYU7TQ045Ce1J
n6WSydNgHZI815MJ6WrZRx4l7cAx6E4pwnLt0uEDqzqQyBbEJZ3TfxXWyQmOvmc07fPPMCABlEnW
He5DkMrsVy1QM/jUlwJQ/092njaoNGP1547cI0uRAZ+0uHjhptsK9fMNooWRa7p1T6J+EH089Ksl
da3kVmZXrGbKvrHxb4GsLIA1UyGt2F4qgS/9c+b688e7lsFfP7CPBRqm64F2qtF3V8FvClgdOBCF
1e6bjAcUoFUVjgwrCfr3ReN05jpvOUT01LQF9IlAY0Bl7BxYzEyccdknhcopkEVirPYU5RlVXpC5
9R6ua49GIYib2mBZdYS1MlK/Xx/yiJGsuzB1V3dSYDkkmqjepTQj0dqNLBJgQu5DmmZd/akEyu34
jeZy95DgMeiYzi/+Ye6FANwNiYQjQHoB2Gh8wadI5ZYImbdjmAED59ClVjWBhe8QkZnC6AysTIh/
icjCL5GdFYwGitnbQeXeVN0zXsbFV3LFLYaIUxK2/E5eArMSYBtBY8I4mLFnonwsun4H2irM3gOR
6XzzX3qOj3hsWNqnHkl6PJuc2Nw3H2AVaPKu99dF5NSXSrXnIPRFmQLIrlU//6kI5Kq5OKGpUv2k
RZ++ObFoOKs0VExs4tih6X8Caf2EaWMDxfLvjwJsrVCIIPiCH/Tsz04jIuYXZ1A0LLlcz+F+l/aw
PI4VK85PPCo9TbWwCXjszfvxAdptQXWL61CGSRlyfIrwXK0evgcSJtPb5MEYZFNrAQjIWo563NqL
ximfWSr2vvFeYlDI288LNK5toHuk4o8FDfnxv5//hVI1ZVi6yoYZVhpHRfX67s6D41MnZVBhNdbq
fHTemGzJVwp2pCt7vBW8CDPBqJVzwjjHyt841tzYdn8pObIuhPY55XTb6PpAHrqqIBbjyWU2/paN
ufsl0znRU2k6o5ds4g+4lLiwcUk9lDdeNo3CilSHXwruhBUCaazI7zCxTQqBXaxsd4iZuIXXf/9t
/FmIXx7ybsTDEYzN4P128uwID301z3rJMLeLRjL0cXvctoeCJfpcMQHTsGhLIkgXVgiBKYlohJ00
vSVzRAQdgRohAxRAmgHkkOTdiD3zSUHQRuHhYK7jTj5JrUReG9PsvFjN5K5/FldJhcucOACHPPJL
e/BuZ1shzgxEfbKz84Xpu5kRRvpAy0JOtWbIV5X8/u3JwjN/4Q/IF1KgNQud6BiS9yBUbbv8PK4C
QdvRv0X4janYuWb0mFXCNQyAkfM7TyFaOCK1FRSg92FJhfrztlb6L8/RAtRQBexKW8SaVMoCUiuL
XyjEX51l7etF9nEVgFJBEIl9yzsd4SmF36Ru3S+OXD7Igxs8rjtH65o5UPFZWxcG15nGMMhQmsZ7
0fP2HOSm34TyaczszUKlcs6UjwqzruW4mSdISbWGcl9b7vi6J8QdU2l/WOHR2frQby6imVyPxlGy
OcEoKk0vhJq1eYsDX/s0UwW/sjjqHfHYg/u8CL/ZFfY4WKWwtrWT9sBDitUekUld0gSTG4jHlLpo
mT/apiHYEb4Y0CEbUKUZYHmEFJp3lIu0EV9tjkjUNNGXtBlyMn+gtsQz6wJQY1vhRsL1/ACZEiI0
3Qa4QGUvuQfRTMIDhK011qHGMnMXe4tcjwoiwT23/c7MDVtmyVt9Ab9thdmKfjZJvsY1eyaeGNg8
pukC8x2EsZDG0SSbGHOoqQnPUlL0fnrhOQssuHMJnZhpZ5SPyQJqCjSq9E9uXguXreZE9OyhyR6E
IzxUxUXmT9zlwn2jKQFLHibz+rBPu1D7mEo/NGU2I28874hex8GLykongh2Xa73znf3HiQ3MBLqk
WLkpea7EeltElFr4azYIvA1pBfoY4V1XdjfbTVsszf7rqhmX81EoTg4+G43E+cZtPrS72eHU9KBz
ZndlIkRBRtgWNujirN65qFseoAbHfk+4QVAA2rsDB/nOl04JJgAhm4TkTXQl1pREPzoYlLm4d4AN
NOWM/ajV+VftOMVn47iBN4DH3WT4ByyOz+S8zLjCKqJmcIYh4Tt/Aq3s5gS7DiuzLbkiuXy+0ak6
0MSkDZW0SXAJ8tZ2XZiQWCKcMguOLRCaqJ3k8oSO6GkUqPMvZRCJTnKBAWpMzrdcR0IfhtnGWQb/
j72h6zbpkCMXyBI3riu4i39ND7VsEOsvAiBpPK3AAnj7h/gqevrKG0Gx6yc8DJABJo37bLnlc58n
LFBfQMK912EhnmEWKsKIqRT3K2XSIG7YC4RMtjB0nLhtINoS48wvFaRJrUa5zJj6miNd9FAcd65u
74GNBGlQtvk2lGDVgPKZBGERBbaGQMTwLsq4GINouvUb0Sn5j5CMwTwsrZk6bWTFPaM6axOwO8Ma
bJDS17/08XwgcormhFAPK1fCQY5xAVbCPB82yzccYZDKhKqXrtrGA3nAz+lGf4/H9JKXrqsyeZ32
Aqk5zmjdwO8FEh4vj+j+ZxN/EvsKwYu6LxWNQm1KEvOBqQIKFaKb+5QiVahC7rVg3XNUAfMGh3v7
WTkzzLWZS/tRyYLYO3l7rO3m248BDMTc5ecQ3cOo7VY9nMKQ7lB1rgh8PUu3gxP07LcKIIiP7CCJ
U9G/h8Iu+hQI8cXDjdIdHOy3jea7G8zDgRFJpVukopz2TS64JCbYQbA2RlwudZjSIlpWTYmuuZ/K
/sGYMDing3iJNhSI0SpdrqLLR0JdxvvMBrOX6MAkKYWfsPve+iEbbV2BnwjT+O30qvHeHEf08ig1
EBph3kdDnwN1WcCc5BEGF8YvxZbZpHWfrInfSBsT61yVizdawu4y2X9dlTyCWeoOJ9c39aSCpoiW
CbEznC5sVpL0P4dCc5OYAd8BIKN+LpE7Si+ztpVU57/ZvG+kR9ocj7tUJ0LcW4bDSgCdeN3U0vXr
ERC+RNVgYBxgqrm1SEitVQb5oZ7b5UqI4HsYJW0FsEgpQQ2alELuwNnN24RiE4sUr3DGizrkPry9
5BJkcvMBM7bk4QZfG7R99RCVvREgFfO4xCJBLkPMtyDA7ok3k6Bw84xPhdpdGMnfa/MHwqewrxGi
8yIHGGoAaJGE9c1n4XDBYcTjsOQascn1A+cV6ypLtM8tzinNf2ejoaBBvqf8lzwS8mhvzo0jPPqs
zFODbfydq+zsVJuC/FFCoR8W0WvJdamSfZ5a5D6laq9nPgVGzLDV1pqLYfa+InP+rJrK1IGo9ykE
jWFNTLqMyEIMC5spbxD6oR4EeJqY7uXmRftsuGre2El7Q5E3IvUEoaqTpU5Hhi0coBZa1VlZRcWv
pmdpiajbsWOyE00mQxFOQGZXzjORhvr+iexJ0fr/ADpgSRMWHNi6cHr+wdsbTlYRrA6klh9W8X33
RaYIBPVE0EsmMUrZ2Yg2IuoVZXWIFWDyHKeqiEHfJRku9nCSGX+l5Pvi+/9GJk5aMprC5NN7XbDO
fBMZxlwTkl0BAWFmuMW4yo63EBgP3JhXThaXffSI7/Xg4dVBNTjvP2UVoI8Y0bFWvLawCirKxoYY
GMH0tSeBewui0Aw4LGmv+s/JZw+RQYDjr1UXdeKKRKbptDIxLW9WDx31cVeb4N356k1x9LddshsW
X28fs2VJIbBid4xYuB+3R2azAhig64OvxpqQMpzoZXzWAKcnXSS2acCemSHCmm2omG/z2S3q3E6F
daDh/Ws/TWOcX/kbkaOxQultQZVI8ID7Sxd4cnirPskAB5MrL+SHdNs+DJkVHiZV7V3Qhzz3NiPU
Hoh/FsEKAqIrvzSpyRD8KwU5mbypOBd+bJm/lT2fQqmJA/pXKO01juKNiDjP6iR3WfzLDb78Rpxl
TQqWaPtk5IVovBXiVbedzp/jEbkDzO5krHPij+FrPh8h5w6AJHpnxWM47joTeXttYVM+Qzgn1Nyc
Pwmm/+B2TvuHGo/9NVEpPuk39eCZawkiGX6MggZwiCles8Dh2bNu1UmDqISNlg28WnLFUhvf52cv
W1YIOnrrC1p5Ct8WMrzHEqMV0PDO7JqkfuLVyLtKOi5dyqZU0ejfoWQqJpeYWGLLToMj8hnGCimZ
1yqXufVQV8FWJcwJKt9z0L/UNblk86irP5zRV0rW37g44Vd7I5EWHBb1aWUS1YFEo94GWggj17P9
fBXua9qLXv0vrd7TPQw8siAGKGz2ZHdAMKA9PSPiGgc6/jz+Sxe+nk/dFlBxS/7nboA3eED3A2o+
k3e4HNioAW+1MoOquhVRhmvuNurzwra+MSSlnui/SvBEJyp52zkuSMzkS9JvfmG6OfJbcL42+WDi
BeiAF059ys8h5/570BFGNpCmfBM0gZnHMW+o3hHD3qfhfZYIJgpb5xv+7eD8Z74QUKyBWsiQKsWq
eEiAR/XofVnR7qtdN3AkZbmzcyGixjpMAPMFB2YyE6j5eTZMOv1ypfFI06ZpWgkDk7kEtJc+/lrq
I2YzuGT4hiwK6n9Mn7liJTlT061pC5tmsdPjDCzqxYLv+z0u4/cwd+TPs46mJnrZOrL7PraLObYp
9tj2TKVJacltOQHpTZcRl84ImF+Xd6FAX94mts1//T5FWOBgT8FVmkpomlHnW1ant/dhUbSUCcTn
Lh5tVA83Nqq0nv7Ml9fRVf7B35cejew2IwwH6DNkw6z5VbA2gyocXxhOlpTGi+tYPkbsjLGBYMHk
XK0FXCN5by1dLl3ajxEEtiTFOam0wwfbUjwkIjHk1AVKgwuo3JhRCt3kED3VRHa5JVfTRnplOJdH
qsl7C21dlNU6AEtJvHXo+aufepR9He0Cr3uOKtF6zsJ4idQQUpZXdYAhx/eBWraKxhRNsyjMZx5R
/LZqAC2nRXBroLXpHWVjKfMwIYKCX5qioeJGn+6A1RlsumyHXUr4l6ZdqGdwPFunrUZAwhOlx8fO
D5IfVqq9yiHT4DuUR7EAtJXlche3ym09chxfEegJUAg645Cm11Km2qa4i9WczabFi/JhZ0jp1etn
Q3nXTweohy+aJrwinfPfJIsRObD782nrTlne7SB0hN/38Tu4HfPeG3MOKRJJZmIFDuB0hSHRhTjW
jXuUtJZkybKEY1fJnlIOH6xp+eZRbFpYCbpIB+P8m8f+qLQaCTSnZVaCZVDR0imwp52invR/lVQV
9aH6cDGp5zojowe2T6LrJjgTTal0wQavV0SxdSpW4yVHW5g1aS5eV+Yjm5n5HwUECDaoaA1zTerQ
GXMINSN1GxRQMz2yGHIQcOxyutFTDiegJYOtiU1+vf+pOHOHGU17BaqrZcBTHETblJEg2/UXcwwF
f/nEu5nut1bFMUW3hGUduWXtYeN9nHK2v7pezvKE0WkH4ZKuyDchdSykjR6h0SqvwVd1rs3DBPNK
893yYl6u36pm27lQS8i3PnxXgrqR5uZI9fymEApcaVw1ZXqjUwnrQkPRjsqCcsGMZG8RoHBEww+g
kZCJUsocKbc5+swotsWTRDd7HgpdvykIN7l0065ua9134qiDLMFdZY7IWr6nnJJIzOP0xuVEYpES
6KnHVkxEo/bc7Ha7BcOf/IRpGhWHNbKafdPrOhTYsbMdnAvAAEu4lF0DTlQboM/OU8QuHgNJQpbA
EVDu7mraAKr54FdDJM8rmUhFbZcaWneK9Qbk8kLvi3dJXb0abcp3gczcMf0kEc6plqFAg/Pg1V+g
FM4nDw8MWcjAPufe2Kuf1NmoBKsOtnVLmwGQ/zq+W1RKWXqr+XOw/uaqRIJEQrldFhGbuabmVw2C
kU+Uo5c1+qwVMAVL1YEl67z5Izdug0wCB3guwmOOvlospuYfPauU2A1LMQrcqf/Hx9QuHn66FMEu
jI1fv1ovfFvXdJXbRp80VoLh4YZJiP5YOkqgBqOrkf2ZGqCDT+Sd9aF9yyLDyMefTNa8bFzYpz59
843mHzmevUU8DM/+rRh5Zq1c37ojf+gr61M5k4HOs1t0tKsG51tJ32J8QsIDdZ01vJTWLyrXez09
daym8yRyLQ0tkdqJsyjIW4UiZUx5NLRfvA4/LojVZkRBMJEkKllqo27vucbEDkWx5tuNCLeSXYbi
neYHAidiVQdH8zWDjoayQQ+HFHThAKeZ4OzYv4ByCurWvC1NOjNmgkDRDqrUIRKbvIPeVFNTJRB2
Owsmt8XNCQUqxuiq571SAiPKX0sSVYch39wBgk/tJlUXhoHLU+nIOvbeAKk3cLd/m1ZVg6/KJ9U3
yAvCJw2J/TcG3eaARRPB/dPuUQFUUg3OKHAqelpofJ+kzsoObHsB/kR/g1DYfoS5Z1MGHIuqMd+7
9cdO77yBPOfuemSuvAAAAABhN0IAKAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/
AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAh3d3d3d3d3d3d3dwAAAAAI//////////////cAAA
AACP/////////////3AAAAAAj/////////////9wAAAAAI//////////////cAAAAACP////////
/////3AAAAAAj/8AD/8AD/8AAP9wAAAAAI//NzAAt7AANzD/cAAAAACP/zt7e3t7e3sw/3AAAAAA
j//ztzMzMzOzD/9wAAAAAI///zsP///zcP//cAAAAACP//83D///87D//3AAAAAAj//zOw/wAAAD
D/9wAAAAAI//87cPAipwAA//cAAAAACP//M7Cqry9wAP/3AAAAAAj///Nwqq/yiAD/9wAAAAAI//
/zsKqqrzj7D/cAAAAACP//O3Cqqv87j7AHAAAAAAj/8zewAAAANzj5EAAAAAAI//N7e3t7e3tzHZ
kAAAAACP/zszMzszMzswHZkAAAAAj/8zP/8zP/8zMPHZkAAAAI//////////////HZkAAACP////
/////////3HZkAAAj//////////4AAAAHZkAAI//////////+P94AAHZkACP//////////j3gAAA
HZkAj//////////4eAAAAAHZkI//////////+IAAAAAAHZCP//////////gAAAAAAAEQiIiIiIiI
iIiIAAAAAAAAAAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA
/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAH8AAAA/AAAAHwAAAA8AAAAH
AAABgwAAA8EAAAfgAAAP8AAAH/gAAD//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8A
AAD/AP8A//8AAP///wAAAAAAAAAAAId3d3d3dwAAj//////3AACP8AAAAPcAAI/3Nzcw9wAAj/MP
/zD3AACP9w8iAPcAAI/zAneHBwAAj/cKqjgBAACP8wqqMJkQAI/3AAAw+ZEAj/NzczD3mRCP////
8AAJkY/////3+ACRj/////eAAACIiIiIiAAAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAA
BwAAAAcAAAAHAAAAAwAAAAEAAAAAAAAADAAAAB8AAAA/AAAAAAEAAgAgIBAAAQAEAOgCAAABABAQ
EAABAAQAKAEAAAIAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAA
AAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAMBAAAWAAAALEEAwDoAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEADAQAAIAAAACZBwMAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA
ANAAAICoAACAAAAAAAAAAAAAAAAAAAABAAwEAADAAAAAwQgDACIAAAAAAAAAAAAAAAcAQQBQAFAA
SQBDAE8ATgBrZXJuZWwzMi5kbGwATG9hZExpYnJhcnlBAEdldFByb2NBZGRyZXNzAOlj9/z/DEAC
AAAAAAAAAAAAwwkDAAxAAgAAAAAAj//zOwqq8vcAD/9wAAAAAI///zcKqv8ogA//cAAAAACP//87
Cqqq84+w/3AAAAAAj//ztwqqr/O4+wBwAAAAAI//M3sAAAADc4+RAAAAAACP/ze3t7e3t7cx2ZAA
AAAAj/87MzM7MzM7MB2ZAAAAAI//Mz//Mz//MzDx2ZAAAACP/////////////x2ZAAAAj///////
//////9x2ZAAAI//////////+AAAAB2ZAACP//////////j/eAAB2ZAAj//////////494AAAB2Z
AI//////////+HgAAAAB2ZCP//////////iAAAAAAB2Qj//////////4AAAAAAABEIiIiIiIiIiI
iAAAAAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A
AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAB/AAAAPwAAAB8AAAAPAAAABwAA
AYMAAAPBAAAH4AAAD/AAAB/4AAA//ygAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA
/wD/AP//AAD///8AAAAAAAAAAACHd3d3d3cAAI//////9wAAj/AAAAD3AACP9zc3MPcAAI/zD/8w
9wAAj/cPIgD3AACP8wJ3hwcAAI/3Cqo4AQAAj/MKqjCZEACP9wAAMPmRAI/zc3Mw95kQj/////AA
CZGP////9/gAkY/////3gAAAiIiIiIgAAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcA
AAAHAAAABwAAAAMAAAABAAAAAAAAAAwAAAAfAAAAPwAAAAABAAIAICAQAAEABADoAgAAAQAQEBAA
AQAEACgBAAACAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAAC
AAEAAABAAACAAgAAAGgAAIAAAAAAAAAAAAAAAAAAAAEADAQAAFgAAACxBAMA6AIAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAwEAACAAAAAmQcDACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQ
AACAqAAAgAAAAAAAAAAAAAAAAAAAAQAMBAAAwAAAAMEIAwAiAAAAAAAAAAAAAAAHAEEAUABQAEkA
QwBPAE4Aa2VybmVsMzIuZGxsAExvYWRMaWJyYXJ5QQBHZXRQcm9jQWRkcmVzcwDpY/f8/wxAAgAA
AAAAAAAAAMMJAwAMQAIAAAAAAI//8zsKqvL3AA//cAAAAACP//83Cqr/KIAP/3AAAAAAj///Owqq
qvOPsP9wAAAAAI//87cKqq/zuPsAcAAAAACP/zN7AAAAA3OPkQAAAAAAj/83t7e3t7e3MdmQAAAA
AI//OzMzOzMzOzAdmQAAAACP/zM//zM//zMw8dmQAAAAj/////////////8dmQAAAI//////////
////cdmQAACP//////////gAAAAdmQAAj//////////4/3gAAdmQAI//////////+PeAAAAdmQCP
//////////h4AAAAAdmQj//////////4gAAAAAAdkI//////////+AAAAAAAARCIiIiIiIiIiIgA
AAAAAAAAAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA
/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAfwAAAD8AAAAfAAAADwAAAAcAAAGD
AAADwQAAB+AAAA/wAAAf+AAAP/8oAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A
/wD//wAA////AAAAAAAAAAAAh3d3d3d3AACP//////cAAI/wAAAA9wAAj/c3NzD3AACP8w//MPcA
AI/3DyIA9wAAj/MCd4cHAACP9wqqOAEAAI/zCqowmRAAj/cAADD5kQCP83NzMPeZEI/////wAAmR
j/////f4AJGP////94AAAIiIiIiIAAAAAAcAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAA
BwAAAAcAAAADAAAAAQAAAAAAAAAMAAAAHwAAAD8AAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEA
BAAoAQAAAgAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgAB
AAAAQAAAgAIAAABoAACAAAAAAAAAAAAAAAAAAAABAAwEAABYAAAAsQQDAOgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQAMBAAAgAAAAJkHAwAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA0AAA
gKgAAIAAAAAAAAAAAAAAAAAAAAEADAQAAMAAAADBCAMAIgAAAAAAAAAAAAAABwBBAFAAUABJAEMA
TwBOAGtlcm5lbDMyLmRsbABMb2FkTGlicmFyeUEAR2V0UHJvY0FkZHJlc3MA6WP3/P8MQAIAAAAA
AAAAAADDCQMADEACAAAAAACP//M7Cqry9wAP/3AAAAAAj///Nwqq/yiAD/9wAAAAAI///zsKqqrz
j7D/cAAAAACP//O3Cqqv87j7AHAAAAAAj/8zewAAAANzj5EAAAAAAI//N7e3t7e3tzHZkAAAAACP
/zszMzszMzswHZkAAAAAj/8zP/8zP/8zMPHZkAAAAI//////////////HZkAAACP////////////
/3HZkAAAj//////////4AAAAHZkAAI//////////+P94AAHZkACP//////////j3gAAAHZkAj///
///////4eAAAAAHZkI//////////+IAAAAAAHZCP//////////gAAAAAAAEQiIiIiIiIiIiIAAAA
AAAAAAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A
AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAH8AAAA/AAAAHwAAAA8AAAAHAAABgwAA
A8EAAAfgAAAP8AAAH/gAAD//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A
//8AAP///wAAAAAAAAAAAId3d3d3dwAAj//////3AACP8AAAAPcAAI/3Nzcw9wAAj/MP/zD3AACP
9w8iAPcAAI/zAneHBwAAj/cKqjgBAACP8wqqMJkQAI/3AAAw+ZEAj/NzczD3mRCP////8AAJkY//
///3+ACRj/////eAAACIiIiIiAAAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcA
AAAHAAAAAwAAAAEAAAAAAAAADAAAAB8AAAA/AAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQA
KAEAAAIAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAA
AEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAMBAAAWAAAALEEAwDoAgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEADAQAAIAAAACZBwMAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICo
AACAAAAAAAAAAAAAAAAAAAABAAwEAADAAAAAwQgDACIAAAAAAAAAAAAAAAcAQQBQAFAASQBDAE8A
TgBrZXJuZWwzMi5kbGwATG9hZExpYnJhcnlBAEdldFByb2NBZGRyZXNzAOlj9/z/DEACAAAAAAAA
AAAAwwkD

------=_NextPart_000_0013_D6DFD6DF.09760976--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJhTMK089722; Wed, 25 May 2005 12:43:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PJhTxP089721; Wed, 25 May 2005 12:43:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4PJhR0d089714 for <[e-mail]>; Wed, 25 May 2005 12:43:28 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C90651A6F5; Wed, 25 May 2005 21:43:26 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 4C60A1A6EC; Wed, 25 May 2005 21:43:22 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 25 May 2005 21:42:43 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: NULL vs. ""
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>

Hi,

in a sieve script (with variable and/or other extensions), can you think 
of a use where a null string works differently from an empty string, in 
a useful way?

One relevant null string could be the value of an absent header field. 
The first of these messages has a null subject, the second an empty 
subject.

---
From: [e-mail]
Date: 24 May 2005 19:52:09 +0100

Body text here
---
From: [e-mail]
Subject:
Date: 24 May 2005 19:52:09 +0100

Body text here
---

I know it's possible to distinguish by looking at whether there is a 
header field at all. But that won't do. I need an example showing how 
differentiating the values of those two header fields could be useful 
and desirable.

If no such example exists, and I've tried really hard to find it, that's 
fine too ;) Then I can say that NULL and "" should be the same.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HJoZAC037916; Tue, 17 May 2005 12:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HJoZXC037915; Tue, 17 May 2005 12:50:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HJoIVh037843 for <[e-mail]>; Tue, 17 May 2005 12:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02313; Tue, 17 May 2005 15:50:15 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-refuse-reject-00.txt
Date: Tue, 17 May 2005 15:50:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: The SIEVE mail filtering language - reject and refuse extensions
	Author(s)	: M. Elvey, A. Melnikov
	Filename	: draft-ietf-sieve-refuse-reject-00.txt
	Pages		: 0
	Date		: 2005-5-17
	
This memo defines the SIEVE mail filtering language [SIEVE]
   "reject" and "refuse" extensions.
   
   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, MDNs
   and messages with complaints.  With the Sieve "reject" action, MDNs
   contribute to the flood of Joe-job spam to victims of Joe-jobs;
   SMTP level refusals usually don't.  With "refuse", Sieve gains the
   ability to simply not accept an email during the SMTP transaction
   (instead of accepting it and then sending an MDN [MDN] back to the
   alleged sender using "reject").

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GJnD3o027500; Mon, 16 May 2005 12:49:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GJnDWC027499; Mon, 16 May 2005 12:49:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GJnCn2027493 for <[e-mail]>; Mon, 16 May 2005 12:49:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 16 May 2005 20:49:09 +0100
Message-ID: <[e-mail]>
Date: Mon, 16 May 2005 20:49:10 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Philip Guenther wrote:

>>My comments:
>>    
>>
>>>4.2 Body Transform ":content"
>>>      
>>>
>>[...]
>>    
>>
>>>  If an individual content type contains a '/' (slash), it
>>>  specifies a full <type>/<subtype> pair, and matches only
>>>  that specific content type.  If it is the empty string, all
>>>  MIME content types are matched.  Otherwise, it specifies a
>>>  <type> only, and any subtype of that type matches it.
>>>      
>>>
>>I would like to see ABNF for the content type and some text explaining 
>>what should be done if the user specified an invalid value here, e.g. 
>>"/". I suspect the answer to this can be: no runtime error, but no match.
>>    
>>
>
>I would rather not drag in ABNF just for this single paragraph.
>Indeed, I suspect the result would be more difficult to comprehend
>when specified that way.  As the only cases not covered by the
>current text are values that begin or end with a slash or contain
>multiple slashes, I've added an initial case to specify that they
>match no content types:
>
>   If an individual content type begins or ends with a '/' (slash) 
>   or contains multiple slashes, it matches no content types.
>  
>
I would suggest something like:

   If an individual content type is not a valid content type according to XXX,
   i.e it begins or ends with a '/' (slash) or contains multiple slashes, it matches no content types.

>   Otherwise, if it contains a slash, then it specifies a full
>   <type>/<subtype> pair, and matches only that specific content   
>   type.  If it is the empty string, all MIME content types are
>   matched.  Otherwise, it specifies a <type> only, and any subtype 
>   of that type matches it.
>  
>
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DJnn41079053; Fri, 13 May 2005 12:49:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DJnnbU079052; Fri, 13 May 2005 12:49:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DJnlKj079044 for <[e-mail]>; Fri, 13 May 2005 12:49:47 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22090; Fri, 13 May 2005 15:49:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-01.txt
Date: Fri, 13 May 2005 15:49:43 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAXpbE084063; Fri, 13 May 2005 03:33:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DAXpig084060; Fri, 13 May 2005 03:33:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAXmXc084008 for <[e-mail]>; Fri, 13 May 2005 03:33:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 13 May 2005 11:33:20 +0100
Message-ID: <[e-mail]>
Date: Fri, 13 May 2005 09:49:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3028bis-00.txt
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:

>FYI, I have already submitted rev -01 incorporating the changes
>discussed in Minneapolis.  I didn't roll them into my resubmission of
>-00 to avoid confusing people about what it contained.
>
>
>Responding to your comments out of order...
>
>Michael Haardt <[e-mail]> writes:
>...
>  
>
>>Address Test For Multiple Addresses Per Header
>>
>>A header may contain multiple addresses.  RFC 3028 does not explicitly
>>specify how to deal with them, but since the "address" test checks if
>>anything matches anything else, matching one address suffices to
>>satify the condition.  That makes it impossible to test if a header
>>contains a certain set of addresses and no more, but it is more logical
>>than letting the test fail if the header contains an additional address
>>besides the one the test checks for.
>>    
>>
>
>Cyrus had forwarded your comment on this to me some time ago, so -01
>includes this sentence in section 5.1:
>	Whether there are other addresses present in the header doesn't
>	affect this test; this test does not provide any way to
>	determine whether an address is the only address in a header.
>  
>
I like that.

>>String Arguments
>>
>>There has been confusion if the string arguments to "require" are to be
>>matched case-sensitive or not.  I suggest to match them with
>>the match type ":is" (default, see section 2.7.1) and the comparator
>>"i;ascii-casemap" (default, see section 2.7.3).  The RFC defines the
>>command defaults clearly, so any different implementations violate RFC
>>3028.  The same is valid for comparator names, also specified as strings.
>>    
>>
>
>Since "require" is not described as taking MATCH-TYPE or COMPARATOR
>arguments, I don't see how the defaults of sections 2.7.1 and 2.7.3 can
>be read as applying.  Whether comparator names are case-sensitive is up
>to the draft defining the collation registry: if it says they are, then
>both comparator strings *and* the string argument to "require" *must* be
>treated as case-sensitive so that all comparator names can be
>specified.
>
>According to draft-newman-i18n-comparator-03.txt, collation names may
>contain both uppercase and lowercase letters.  I see nothing in the
>draft that would have them treated as case-insensitive.  Given that, I
>don't see how sieve can specify those strings to be case-insensitive.
>  
>
In this case I think it might be better to explicitly say that the 
require parameter is case-sensitive.

>>Strings Containing Header Names Or Envelope Elements
>>
>>RFC 3028 does not specify what happens if a string denoting a header field
>>or envelope element does not contain a valid name, e.g. it contains a
>>colon for a header or it is not "from" or "to" for envelopes.
>>    
>>
>
>Look closer.  2.4.2.2p2:
>	A header name never contains a colon.  The "From" header refers
>	to a line beginning "From:" (or "From   :", etc.).  No header
>	will match the string "From:" due to the trailing colon.
>
>As for "envelope", I think the current phrasing ("If one of the
>envelope-part strings...") could be read to imply that envelope-part
>strings other than "from" and "to" are simply ignored.  However, that's
>certainly not as clear as 2.4.2.2's statement for bogus header names.
>
>(Indeed, I just checked and Sendmail's implementation gives a syntax
>error on envelope-part strings other than "from" and "to".)
>  
>
>>I suggest
>>generating an error instead of ignoring the header field in order to
>>ease script debugging, which fits in the common picture of Sieve.
>>    
>>
>
><editor-hat off>
>I am opposed to reversing the existing statement in 2.4.2.2, as the
>existing text is quite clear and unambiguous.
>  
>
<chair-hat off>I agree</chair-hat off>

>I am mildly in support of making it an error for envelope as a
>clarification, but think more people should speak to the point.
>  
>
<chair-hat off>I agree</chair-hat off>

><editor-hat on>
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CDPews082381; Thu, 12 May 2005 06:25:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CDPepS082380; Thu, 12 May 2005 06:25:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CDPbis082372 for <[e-mail]>; Thu, 12 May 2005 06:25:38 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id F0FCFC8E4F9; Thu, 12 May 2005 09:25:35 -0400 (EDT)
X-Sasl-enc: cx4j4Nk3CfuunnQBXLyblHNZm4b+UsSp+dnL0DSv1ECP 1115904335
Received: from [192.168.2.98] (adsl-67-112-26-159.dsl.snfc21.pacbell.net [67.112.26.159]) by frontend3.messagingengine.com (Postfix) with ESMTP id F01C91DC; Thu, 12 May 2005 09:25:32 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 06:25:34 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], Alexey Melnikov <[e-mail]>, Philip Guenther <[e-mail]>
Subject: refuse (was Re: Responses to ... editheader-00
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <MNA5wwkw9mmWwiCm/aKm/[e-mail]>
In-Reply-To: <MNA5wwkw9mmWwiCm/aKm/[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
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>

On 5/12/05 5:05 AM, Arnt Gulbrandsen sent forth electrons to convey:

>
> Alexey Melnikov writes:
>
>> The text in -01 effectively says that "reject" should use the 
>> modified message. How is "refuse" different? If "refuse" uses an 
>> SMTP/LMTP response, than there is no message?
>
>
> Exactly.
>
> Arnt
>
Or as I wrote on 5/9 in the latest revision of draft-ietf-sieve-refuse I 
sent Alexey:

> Any action that would modify the message body will necessarily have no 
> effect on the body of any message refused by "refuse" using the 550 
> SMTP response code.

Since it now defines reject too, perhaps draft-ietf-sieve-refuse is the 
wrong name... Let's go with draft-ietf-sieve-refuse-and-reject.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCJh0C063474; Thu, 12 May 2005 05:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CCJhmT063473; Thu, 12 May 2005 05:19:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCJgkZ063462 for <[e-mail]>; Thu, 12 May 2005 05:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.175] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 12 May 2005 13:19:24 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 13:19:24 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
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:

>Alexey Melnikov wrote:
>  
>
>>>  Actions that create messages in storage or in transport to
>>>  MTAs MUST store and send messages with the current set of
>>>  header fields.
>>>      
>>>
>>                       
>>I am not sure I understand what is "in transport to MTAs", is this
>>trying to say "in MTA's queue"?
>>    
>>
>
>It's trying to say that if you do something like forward the message,
>the forwarded content reflects any changes.  Would it be clearer
>if that sentence was simplified to
>
>   Actions that store or send the message MUST do so with the
>   current set of header fields.
>  
>
>?
>  
>
Yes, that is much better. Thanks.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CC69ED058905; Thu, 12 May 2005 05:06:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CC69Zs058904; Thu, 12 May 2005 05:06:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CC688R058887 for <[e-mail]>; Thu, 12 May 2005 05:06:09 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id AF5F01A6F1; Thu, 12 May 2005 14:06:16 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 8441C1A6C8; Thu, 12 May 2005 14:06:10 +0200 (CEST)
Message-Id: <MNA5wwkw9mmWwiCm/aKm/[e-mail]>
Date: Thu, 12 May 2005 14:05:14 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
Cc: Alexey Melnikov <[e-mail]>, Philip Guenther <[e-mail]>
References: <[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:
> The text in -01 effectively says that "reject" should use the modified 
> message. How is "refuse" different? If "refuse" uses an SMTP/LMTP 
> response, than there is no message?

Exactly.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CC2oOo057797; Thu, 12 May 2005 05:02:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CC2ohs057795; Thu, 12 May 2005 05:02:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CC2m4o057777 for <[e-mail]>; Thu, 12 May 2005 05:02:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.175] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 12 May 2005 13:02:46 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 13:02:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], Philip Guenther <[e-mail]>
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

>
> Philip Guenther writes:
>
>> Arnt Gulbrandsen wrote:
>>
>>> Another minor point: If a message is rejected after being modified, 
>>> which version of the message should be sent to the bounce address, 
>>> the original message or the one with a modified header?
>>
>>
>> The one with the modified header. This was covered by the "Actions 
>> that create messages..." sentence in section 5, which I'm changing to 
>> the "Actions that store or send the message..." sentence mentioned 
>> above.
>
>
> Fine with me.
>
> Please note specifically that addheader/refuse won't use the modified 
> message, though. (Yes, I realize that for all known current 
> implementations, addheader/refuse isn't possible in the first place.)

The text in -01 effectively says that "reject" should use the modified 
message. How is "refuse" different? If "refuse" uses an SMTP/LMTP 
response, than there is no message?

> It could be (I don't know, nor really care) that you should mention 
> that addheader/reject in that order could expose information 
> unintended, so users should be careful where appropriate.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AK0mAm055615; Tue, 10 May 2005 13:00:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AK0m5h055614; Tue, 10 May 2005 13:00:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AK0lkr055606 for <[e-mail]>; Tue, 10 May 2005 13:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08296; Tue, 10 May 2005 16:00:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-body-01.txt
Date: Tue, 10 May 2005 16:00:45 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-01.txt
	Pages		: 0
	Date		: 2005-5-10
	
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-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-body-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-body-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-body-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJx316054990; Tue, 10 May 2005 12:59:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AJx3JX054989; Tue, 10 May 2005 12:59:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJx2to054982 for <[e-mail]>; Tue, 10 May 2005 12:59:02 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08004; Tue, 10 May 2005 15:59:00 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-01.txt
Date: Tue, 10 May 2005 15:58:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve: An Email Filtering Language
	Author(s)	: P. Guenther
	Filename	: draft-ietf-sieve-3028bis-01.txt
	Pages		: 38
	Date		: 2005-5-10
	
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-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-3028bis-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-3028bis-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-3028bis-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJwkZr054960; Tue, 10 May 2005 12:58:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AJwkf1054959; Tue, 10 May 2005 12:58:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJwjnp054935 for <[e-mail]>; Tue, 10 May 2005 12:58:46 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07951; Tue, 10 May 2005 15:58:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-01.txt
Date: Tue, 10 May 2005 15:58:43 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-01.txt
	Pages		: 0
	Date		: 2005-5-10
	
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-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-editheader-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-editheader-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-editheader-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJNcaa052193; Tue, 10 May 2005 12:23:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AJNc5x052192; Tue, 10 May 2005 12:23:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJNbFO052181 for <[e-mail]>; Tue, 10 May 2005 12:23:37 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4AJNNIa009730 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 May 2005 12:23:23 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j4AJNNIa009730
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=sc4t1w9YLFWUjGvZhTylEwNab1xjdZJuigrGeRix7NWQs4g/295WriF0stJCT+NbO sWDSPEFbyqEA6w2wZ8Uy/4Y+8yJm4CzKWhqFKQpQJW340zsep1QR6vfN61qMbRsA2LH vfJqHec8/IJcX9YJWuQlc/sL35J9fdyT+O6uqXo=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j4AJNM5q002495; Tue, 10 May 2005 12:23:22 -0700 (PDT) (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-3028bis-00.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Tue, 10 May 2005 12:23:22 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI, I have already submitted rev -01 incorporating the changes
discussed in Minneapolis.  I didn't roll them into my resubmission of
-00 to avoid confusing people about what it contained.


Responding to your comments out of order...

Michael Haardt <[e-mail]> writes:
...
>Address Test For Multiple Addresses Per Header
>
>A header may contain multiple addresses.  RFC 3028 does not explicitly
>specify how to deal with them, but since the "address" test checks if
>anything matches anything else, matching one address suffices to
>satify the condition.  That makes it impossible to test if a header
>contains a certain set of addresses and no more, but it is more logical
>than letting the test fail if the header contains an additional address
>besides the one the test checks for.

Cyrus had forwarded your comment on this to me some time ago, so -01
includes this sentence in section 5.1:
	Whether there are other addresses present in the header doesn't
	affect this test; this test does not provide any way to
	determine whether an address is the only address in a header.


>String Arguments
>
>There has been confusion if the string arguments to "require" are to be
>matched case-sensitive or not.  I suggest to match them with
>the match type ":is" (default, see section 2.7.1) and the comparator
>"i;ascii-casemap" (default, see section 2.7.3).  The RFC defines the
>command defaults clearly, so any different implementations violate RFC
>3028.  The same is valid for comparator names, also specified as strings.

Since "require" is not described as taking MATCH-TYPE or COMPARATOR
arguments, I don't see how the defaults of sections 2.7.1 and 2.7.3 can
be read as applying.  Whether comparator names are case-sensitive is up
to the draft defining the collation registry: if it says they are, then
both comparator strings *and* the string argument to "require" *must* be
treated as case-sensitive so that all comparator names can be
specified.

According to draft-newman-i18n-comparator-03.txt, collation names may
contain both uppercase and lowercase letters.  I see nothing in the
draft that would have them treated as case-insensitive.  Given that, I
don't see how sieve can specify those strings to be case-insensitive.


>Strings Containing Header Names Or Envelope Elements
>
>RFC 3028 does not specify what happens if a string denoting a header field
>or envelope element does not contain a valid name, e.g. it contains a
>colon for a header or it is not "from" or "to" for envelopes.

Look closer.  2.4.2.2p2:
	A header name never contains a colon.  The "From" header refers
	to a line beginning "From:" (or "From   :", etc.).  No header
	will match the string "From:" due to the trailing colon.

As for "envelope", I think the current phrasing ("If one of the
envelope-part strings...") could be read to imply that envelope-part
strings other than "from" and "to" are simply ignored.  However, that's
certainly not as clear as 2.4.2.2's statement for bogus header names.

(Indeed, I just checked and Sendmail's implementation gives a syntax
error on envelope-part strings other than "from" and "to".)


>I suggest
>generating an error instead of ignoring the header field in order to
>ease script debugging, which fits in the common picture of Sieve.

<editor-hat off>
I am opposed to reversing the existing statement in 2.4.2.2, as the
existing text is quite clear and unambiguous.

I am mildly in support of making it an error for envelope as a
clarification, but think more people should speak to the point.
<editor-hat on>



>Undefined Test Results
..
>Note that by considering Sieve to be a MUA, RFC 2047 can be interpreted
>in a way that NUL characters truncating strings is allowed for Sieve
>implementations, although not recommended.  It is further allowed to use
>encoded NUL characters in headers, but that's not recommended either.
>The above example shows why.  RFC 3028 should say something about this issue.
...
>Header Test With Invalid MIME Encoding In Header
>
>Some MUAs process invalid base64 encoded data, generating junk.
>Others ignore junk after seeing an equal sign in base64 encoded data.
>RFC 2047 does not specify how to react in this case, other than stating
>that a client must not forbid to process a message for that reason.
>RFC 2045 specifies that invalid data should be ignored (appearantly
>looking at end of line characters).  It also specifies that invalid data
>may lead to rejecting messages containing them (and there it appears to
>talk about true encoding violations), which is a clear contradiction to
>ignoring them.
>
>RFC 3028 does not specify how to process incorrect MIME words.  I suggest
>to treat them literally, as I do if the word is correct, but its character
>set can not be converted to UTF-8.

Hmm.  To paraphrase (and mangle) something that Dave Crocker said at the
meeting in Minneapolis: when there's a spec for something, it's a bad
idea to try to address general problems arising from it anywhere but in
that spec.  He was speaking then to the question of whether the
'vacation' draft should go into the issues around permitting users to
set the "From" on outgoing messages, noting that this is a general issue
for mail submission and that 'vacation' should not try to apply a
point-fix to the problem, though a security consideration pointing at
the submission RFC would be appropriate.

I think the same logic applies here.  The MIME RFCs describe the issues;
the sieve spec should simply include a security consideration on the
general points with a specific comment on how it's placement as a filter
may make these choices more critical than in a normal MUA, as they may
limit the user's ability to protect themselves from bad data.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ACjevF011751; Tue, 10 May 2005 05:45:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4ACjedr011750; Tue, 10 May 2005 05:45:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ACjcae011731 for <[e-mail]>; Tue, 10 May 2005 05:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.51) id 1DVU7B-0005eg-K8 for [e-mail]; Tue, 10 May 2005 14:45:33 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #1) id 1DVU7B-0002YL-GT for [e-mail]; Tue, 10 May 2005 14:45:33 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #1) id 1DVU77-0006Fw-Cq for [e-mail]; Tue, 10 May 2005 14:45:29 +0200
Date: Tue, 10 May 2005 14:45:29 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3028bis-00.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>

I guess that means the discussion is opened.  Here are my relevant notes
on RFC 3028.


Undefined Test Results

Implementations that use C-style strings will only evaluate the first
test as true.

Subject: =?iso-8859-1?q?abc=00def

header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]

Note that by considering Sieve to be a MUA, RFC 2047 can be interpreted
in a way that NUL characters truncating strings is allowed for Sieve
implementations, although not recommended.  It is further allowed to use
encoded NUL characters in headers, but that's not recommended either.
The above example shows why.  RFC 3028 should say something about this issue.


Strings Containing Header Names Or Envelope Elements

RFC 3028 does not specify what happens if a string denoting a header field
or envelope element does not contain a valid name, e.g. it contains a
colon for a header or it is not "from" or "to" for envelopes.  I suggest
generating an error instead of ignoring the header field in order to
ease script debugging, which fits in the common picture of Sieve.


Header Test With Invalid MIME Encoding In Header

Some MUAs process invalid base64 encoded data, generating junk.
Others ignore junk after seeing an equal sign in base64 encoded data.
RFC 2047 does not specify how to react in this case, other than stating
that a client must not forbid to process a message for that reason.
RFC 2045 specifies that invalid data should be ignored (appearantly
looking at end of line characters).  It also specifies that invalid data
may lead to rejecting messages containing them (and there it appears to
talk about true encoding violations), which is a clear contradiction to
ignoring them.

RFC 3028 does not specify how to process incorrect MIME words.  I suggest
to treat them literally, as I do if the word is correct, but its character
set can not be converted to UTF-8.


Address Test For Multiple Addresses Per Header

A header may contain multiple addresses.  RFC 3028 does not explicitly
specify how to deal with them, but since the "address" test checks if
anything matches anything else, matching one address suffices to
satify the condition.  That makes it impossible to test if a header
contains a certain set of addresses and no more, but it is more logical
than letting the test fail if the header contains an additional address
besides the one the test checks for.


String Arguments

There has been confusion if the string arguments to "require" are to be
matched case-sensitive or not.  I suggest to match them with
the match type ":is" (default, see section 2.7.1) and the comparator
"i;ascii-casemap" (default, see section 2.7.3).  The RFC defines the
command defaults clearly, so any different implementations violate RFC
3028.  The same is valid for comparator names, also specified as strings.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A5b8ip054378; Mon, 9 May 2005 22:37:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A5b8js054377; Mon, 9 May 2005 22:37:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A5b7Fc054357 for <[e-mail]>; Mon, 9 May 2005 22:37:07 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4A5b49f007646 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 9 May 2005 22:37:05 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j4A5b49f007646
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=R/7tM3afUYyEBcOWbCRkFz6X5ZtuNG2KDvLpdJ0BYto8liAtkMjoshn4Z+Gg9jOQb gLw9YvzrccG0roZbDOWnlX4pd6Bwy5D9nqr7lGATGlCxsbIv/zDkhDUX9nVZCOzxvTr hH4/DMSLygEOYjYe8EHpxxwNDWaWgzKPR866K+E=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j4A5b4v7024372; Mon, 9 May 2005 22:37:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Mon, 09 May 2005 22:37:04 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Mark E. Mallett" <[e-mail]> writes:
>On Sun, May 01, 2005 at 06:27:14PM -0700, Philip Guenther wrote:
...
>> Yeah.  To clarify, I've replaced the second/last sentence of that
>> paragraph with:
>> 	All MIME parts with matching types are searched for the key
>> 	strings.
>
>That doesn't actually do the clarification, though.  The question was
>whether the search result is the OR of all the tests, or the AND of all
>the tests.  That is, does a match in just one of the candidate parts
>satisfy the test, or does the match have to appear in *all* of the
>candidate parts.

Ah, I understand now.  I'll add "The test returns true if any
combination of searched MIME part and key-list argument match."


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49JtDIf094250; Mon, 9 May 2005 12:55:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49JtDjM094249; Mon, 9 May 2005 12:55:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49JtCvK094243 for <[e-mail]>; Mon, 9 May 2005 12:55:13 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26389; Mon, 9 May 2005 15:55:07 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-00.txt
Date: Mon, 09 May 2005 15:55:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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)	: P. Guenther
	Filename	: draft-ietf-sieve-3028bis-00.txt
	Pages		: 39
	Date		: 2005-5-9
	
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-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-3028bis-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-3028bis-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-3028bis-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44LeC6H014487; Wed, 4 May 2005 14:40:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44LeCgs014486; Wed, 4 May 2005 14:40:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j44LeAvH014471 for <[e-mail]>; Wed, 4 May 2005 14:40:11 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 50113 invoked by uid 101); 4 May 2005 17:40:10 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 4 May 2005 17:40:10 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, Tony Finch <[e-mail]>, [e-mail]
Subject: Re: vacation and envelope-to: another try
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 04, 2005 at 06:39:46PM +0200, Kjetil Torgrim Homme wrote:
> On Wed, 2005-05-04 at 17:48 +0200, Kjetil Torgrim Homme wrote:
> > IMO it is a reasonable interpretation to use the _latest_ ("final" if
> > you will) recipient address.  never mind the fact that the latest RCPT
> > TO happened across LMTP rather than SMTP.  I think the base spec should
> > be changed to reflect this more clearly.  I would prefer wording which
> > allowed Cyrus to work like today, leaving alias knowledge to the MTA.
> > changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
> > probably won't do for Mark.  suggestions?
> 
> I'm embarrassed to admit that my reading skills are extremely lacking.
> RFC 3028 says, just two paragraphs down from my earlier quote:
> 
>    If a protocol other than SMTP is used for message transport,
>    implementations are expected to adapt this command appropriately.

On the other hand, "transport" != "delivery" when we talk about email
architecture.  And when an RFC talks about RCPT TO, and transport
commands, well... it reads the way it reads.  Sounds like there's at
least some support for interpreting this as a (possibly munged) final
recipient address, so maybe that's something to think about clarifying
for 3028bis.

People are agreeing; I'm not arguing, honest...

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44GkTGL085326; Wed, 4 May 2005 09:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44GkTNa085325; Wed, 4 May 2005 09:46:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44GkSwo085319 for <[e-mail]>; Wed, 4 May 2005 09:46:28 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 May 2005 09:46:26 -0700 (PDT)
Cc: Mark E Mallett <[e-mail]>, Tony Finch <[e-mail]>, [e-mail]
Date: Wed, 04 May 2005 09:27:44 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Wed, 04 May 2005 17:48:22 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: vacation and envelope-to: another try
To: Kjetil Torgrim Homme <[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, 2005-05-04 at 10:11 -0400, Mark E. Mallett wrote:
> > PS: my own implementation uses the final delivery address as the address
> > in the 'envelope "to"' sieve test, contrary to RFC3028 which says that
> > the SMTP RCPT TO address must be used.  You all can tell me how wrong
> > this choice of implementation is, and I would simply have to agree that
> > it's a violation, but I just don't find the RCPT TO address to be of
> > anywhere near as much interest to the script as the actual resolved
> > individual delivery address; not to mention the fact that the RCPT TO
> > address can't nececessarily be guaranteed to be consistent as
> > implementations evolve.

> _which_ SMTP RCPT TO?

Exactly what I was thinking.

> in many environments, the expansion happens at one server and delivery
> at another.  it's simply impossible to pass information about the
> "original" RCPT TO on to the next server when the alias is an actual
> expansion (ie. more than one recipient address).

And more to the point, the fact that a given recipient address hasn't actually
appeared in an SMTP dialogue in a RCPT TO field is 100% irrelevant. The message
envelope and its associated list of recipients is an abstraction that manifests
in a variety of ways, including but not limited to SMTP commands.

Another way to look at it is that when we talk about RCPT TO addresses we're
referring to the addresses in the envelope recipient list, not to those
addresses in the specific case where they happen to appear in SMTP. The
terminology choie is unfortunate, but after over 20 years changing it is simply
not realistic.

> 3028 even says as much:

>    If one of the envelope-part strings is (case insensitive) "to", then
>    matching occurs against the TO address used in the SMTP RCPT command
>    that resulted in this message getting delivered to this user.  Note
>    that only the most recent TO is available, and only the one relevant
>    to this user.

> what's a "final delivery address"?

FWIW it's defined, more or less, as part of the NOTARY specifications.

> in our case with Cyrus as the server, the delivery address isn't
> necessarily a routable e-mail address(!), as it's rewritten from
> f.m.lastname+detail@domain to username+detail@domain.  in other words,
> our system is contrary to RFC 3028, too.  (I should point out that Cyrus
> can be used in a strictly compliant manner, but not at our site.)

There are really two issues here that overlap to some extent. One is the issue
that arises when a recipient address gets turned into something that isn't
globally meaningful or usable. properly. The other is what address to expose to
sieve for the purposes of performing envelope recipient tests.

THe overlap is only partial since there can be multiple global addresses
involved in addition to local addresses, so the choice of address to
expose isn't simply local/global.

Quite a few systems, ours included, use oddball local address forms at the
point of final delivery. I personally don't like this much, but in our case the
design was a fait accompli long before I was even involved. Even so, when this
is done the goal needs to be to minimize exposure of these local address forms,
for one simple reason: They don't work when someone enters then into their
email client.

As far as selecting the right address to use in envelope tests goes, I like to
apply the least astonishment principle: Use the address the user expects.

> IMO it is a reasonable interpretation to use the _latest_ ("final" if
> you will) recipient address.  never mind the fact that the latest RCPT
> TO happened across LMTP rather than SMTP. 

Or even if there was no protocol involved at all.

> I think the base spec should
> be changed to reflect this more clearly.  I would prefer wording which
> allowed Cyrus to work like today, leaving alias knowledge to the MTA.
> changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
> probably won't do for Mark.  suggestions?

I tend to use the term "envelope recipient" or "final envelope recipient" or
something similar if I'm trying to avoid tying things to SMTP specifically. But
the reality is that the term "RCPT TO" is now used all the time for this even
when SMTP isn't necessarily part of the picture.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Ge4Gu083767; Wed, 4 May 2005 09:40:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44Ge4Cb083766; Wed, 4 May 2005 09:40:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Ge3pK083751 for <[e-mail]>; Wed, 4 May 2005 09:40:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DTMui-00014X-4F; Wed, 04 May 2005 18:39:56 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DTMue-00064c-QL; Wed, 04 May 2005 18:39:52 +0200
Subject: Re: vacation and envelope-to: another try
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Tony Finch <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 04 May 2005 18:39:46 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.882, required 12, autolearn=disabled, AWL 2.07, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2005-05-04 at 17:48 +0200, Kjetil Torgrim Homme wrote:
> IMO it is a reasonable interpretation to use the _latest_ ("final" if
> you will) recipient address.  never mind the fact that the latest RCPT
> TO happened across LMTP rather than SMTP.  I think the base spec should
> be changed to reflect this more clearly.  I would prefer wording which
> allowed Cyrus to work like today, leaving alias knowledge to the MTA.
> changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
> probably won't do for Mark.  suggestions?

I'm embarrassed to admit that my reading skills are extremely lacking.
RFC 3028 says, just two paragraphs down from my earlier quote:

   If a protocol other than SMTP is used for message transport,
   implementations are expected to adapt this command appropriately.

so the spec is fine already, IMHO.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44FmfuL075843; Wed, 4 May 2005 08:48:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44Fmfbm075842; Wed, 4 May 2005 08:48:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Fmd3K075824 for <[e-mail]>; Wed, 4 May 2005 08:48:40 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DTM70-0002tc-LW; Wed, 04 May 2005 17:48:34 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DTM6v-0000Im-BT; Wed, 04 May 2005 17:48:29 +0200
Subject: Re: vacation and envelope-to: another try
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Tony Finch <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 04 May 2005 17:48:22 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.894, required 12, autolearn=disabled, AWL 2.06, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2005-05-04 at 10:11 -0400, Mark E. Mallett wrote:
> PS: my own implementation uses the final delivery address as the address
> in the 'envelope "to"' sieve test, contrary to RFC3028 which says that
> the SMTP RCPT TO address must be used.  You all can tell me how wrong
> this choice of implementation is, and I would simply have to agree that
> it's a violation, but I just don't find the RCPT TO address to be of
> anywhere near as much interest to the script as the actual resolved
> individual delivery address; not to mention the fact that the RCPT TO
> address can't nececessarily be guaranteed to be consistent as
> implementations evolve.

_which_ SMTP RCPT TO?

in many environments, the expansion happens at one server and delivery
at another.  it's simply impossible to pass information about the
"original" RCPT TO on to the next server when the alias is an actual
expansion (ie. more than one recipient address).  3028 even says as
much:

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is available, and only the one relevant
   to this user.

what's a "final delivery address"?

in our case with Cyrus as the server, the delivery address isn't
necessarily a routable e-mail address(!), as it's rewritten from
f.m.lastname+detail@domain to username+detail@domain.  in other words,
our system is contrary to RFC 3028, too.  (I should point out that Cyrus
can be used in a strictly compliant manner, but not at our site.)

IMO it is a reasonable interpretation to use the _latest_ ("final" if
you will) recipient address.  never mind the fact that the latest RCPT
TO happened across LMTP rather than SMTP.  I think the base spec should
be changed to reflect this more clearly.  I would prefer wording which
allowed Cyrus to work like today, leaving alias knowledge to the MTA.
changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
probably won't do for Mark.  suggestions?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44ET51g064536; Wed, 4 May 2005 07:29:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44ET4Q2064533; Wed, 4 May 2005 07:29:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44ET4iT064517 for <[e-mail]>; Wed, 4 May 2005 07:29:04 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 May 2005 07:29:01 -0700 (PDT)
Cc: [e-mail], [e-mail], Mark E Mallett <[e-mail]>
Date: Wed, 04 May 2005 07:24:32 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Wed, 04 May 2005 13:09:07 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: vacation and envelope-to: another try
To: Arnt Gulbrandsen <[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>

> [e-mail] writes:
> > I have no problem calling out that the current envelope recipient
> > address as an additional source of information for this check. I'll
> > add text to this effect to the revision.

> Make sure to define "current envelope recipient address" as the address
> _after_ alias resolution at the final destination, ie. not the address
> seen in the SMTP conversation. Otherwise mail to [e-mail] would
> likely trigger vacation responses from all absent team members.

By definition sieve operates at or around the time of final delivery. Aliases
necessarily have to be expanded prior to this point. I suppose an
implementation could have squirreled away original address information
somewhere/somehow, but how someone could mistakenly see it as appropriate to
use this material as a "current envelope address" escapes me.

Nevertheless, if it makes people feel better, I'll change the phrase to
read "final recipient address".

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44ELVXP063452; Wed, 4 May 2005 07:21:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44ELVjK063451; Wed, 4 May 2005 07:21:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44ELUQM063439 for <[e-mail]>; Wed, 4 May 2005 07:21:30 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 May 2005 07:21:26 -0700 (PDT)
Cc: [e-mail], Mark E Mallett <[e-mail]>
Date: Wed, 04 May 2005 07:20:35 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Wed, 04 May 2005 13:24:26 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
To: Arnt Gulbrandsen <[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 writes (about replaceheader)
> > To me, it's "pick your evil." One adds to the proliferation of
> > extensions, and separates things that really should be together. The
> > other delays the standardization of 2/3 of those things.

> I think that view is too optimisic. I think the other _prevents_, etc.

> If we repeat the 2003 discussion now, what will that change? AFAICT,
> nothing. I can't think of anything that has changed in the past two
> years, so we'll just spend a few months, arrive at the same conclusion
> as last time, and the draft will be x more months delayed.

Speaking as one of the people who wanted replaceheader back, I reluctantly
have to agree with this assessment. Let's move forward with what's there
now.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EBjAS062061; Wed, 4 May 2005 07:11:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44EBj2r062060; Wed, 4 May 2005 07:11:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j44EBiMY062054 for <[e-mail]>; Wed, 4 May 2005 07:11:44 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 98512 invoked by uid 101); 4 May 2005 10:11:44 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 4 May 2005 10:11:43 -0400
To: Tony Finch <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: vacation and envelope-to: another try
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.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 04, 2005 at 12:10:14PM +0100, Tony Finch wrote:
> "Mark E. Mallett" <[e-mail]> wrote:
> >
> >   "Vacation" MUST NOT respond to a message unless a valid email address
> >   for the recipient appears in a "To", "Cc", "Bcc", "Resent-To",
> >   "Resent-Cc", or "Resent-Bcc" line of the original message.  An email
> >   address is valid for the recipient only if it is one of: an email
> >   address known by the implementation to belong to the recipient; the
> >   envelope recipient address if it's available to the implementation;
> >   any other address specified by the script writer via the ":addresses"
> >   tagged option.
> 
> This fails if the envelope recipient address is an alias that expands to
> more than one address before delivery to the user in question. The
> intermediate results of expansion might not be available to the Sieve
> implementation.

Absolutely- what I had in mind was the final recipient address; the
personal email address that had been resolved and resulted in the
ultimate delivery to the user.  If it's available to the implementation,
of course.  This is what I attempted to describe in narrative, and
referring to it as "envelope recipient" is probably one place where I
confused things (see below too).  Using the "RCPT TO" address or any
unexpanded multi-recipient alias for this test would certainly be wrong.

-mm-

PS: my own implementation uses the final delivery address as the address
in the 'envelope "to"' sieve test, contrary to RFC3028 which says that
the SMTP RCPT TO address must be used.  You all can tell me how wrong
this choice of implementation is, and I would simply have to agree that
it's a violation, but I just don't find the RCPT TO address to be of
anywhere near as much interest to the script as the actual resolved
individual delivery address; not to mention the fact that the RCPT TO
address can't nececessarily be guaranteed to be consistent as
implementations evolve.  For example, an environment might at some point
expand aliases by re-injecting the individual addresses via SMTP or LMTP
where it didn't do so before.  The fact that I've implemented it this
way has colored the way I've talked about it in this thread, which is a
big error on my part.  Sorry about that.  I still stand by the actual
suggestion, though.

(Maybe a better way to provide this rfc-violating envelope test would be
to use a different "envelope-part" keyword.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BHppa003659; Wed, 4 May 2005 04:17:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44BHpm8003658; Wed, 4 May 2005 04:17:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BHppQ003641 for <[e-mail]>; Wed, 4 May 2005 04:17:51 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Wed, 4 May 2005 13:24:26 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
Cc: "Mark E. Mallett" <[e-mail]>
References: <[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>

Mark E. Mallett writes (about replaceheader)
> To me, it's "pick your evil." One adds to the proliferation of 
> extensions, and separates things that really should be together. The 
> other delays the standardization of 2/3 of those things.

I think that view is too optimisic. I think the other _prevents_, etc.

If we repeat the 2003 discussion now, what will that change? AFAICT, 
nothing. I can't think of anything that has changed in the past two 
years, so we'll just spend a few months, arrive at the same conclusion 
as last time, and the draft will be x more months delayed.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BALHd099909; Wed, 4 May 2005 04:10:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44BALhI099908; Wed, 4 May 2005 04:10:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from chiark.greenend.org.uk ([e-mail] [193.201.200.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BAKYP099884 for <[e-mail]>; Wed, 4 May 2005 04:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path [e-mail]) id 1DTHle-0005fV-00; Wed, 04 May 2005 12:10:14 +0100
To: [e-mail]
From: Tony Finch <[e-mail]>
Cc: [e-mail]
Subject: Re: vacation and envelope-to: another try
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 04 May 2005 12:10:14 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Mark E. Mallett" <[e-mail]> wrote:
>
>   "Vacation" MUST NOT respond to a message unless a valid email address
>   for the recipient appears in a "To", "Cc", "Bcc", "Resent-To",
>   "Resent-Cc", or "Resent-Bcc" line of the original message.  An email
>   address is valid for the recipient only if it is one of: an email
>   address known by the implementation to belong to the recipient; the
>   envelope recipient address if it's available to the implementation;
>   any other address specified by the script writer via the ":addresses"
>   tagged option.

This fails if the envelope recipient address is an alias that expands to
more than one address before delivery to the user in question. The
intermediate results of expansion might not be available to the Sieve
implementation.

Tony.
-- 
f.a.n.finch  <[e-mail]>  http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: NORTH 4 OR 5, LOCALLY 6
AT FIRST, DECREASING 3 OR 4. FAIR, RISK OF RAIN AT FIRST. MAINLY GOOD.
MODERATE TO ROUGH BECOMING SLIGHT TO MODERATE.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44B2YTF097143; Wed, 4 May 2005 04:02:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44B2Y3k097142; Wed, 4 May 2005 04:02:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44B2WIu097120 for <[e-mail]>; Wed, 4 May 2005 04:02:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Wed, 4 May 2005 13:09:07 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: vacation and envelope-to: another try
Cc: [e-mail], Mark E Mallett <[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>

[e-mail] writes:
> I have no problem calling out that the current envelope recipient 
> address as an additional source of information for this check. I'll 
> add text to this effect to the revision.

Make sure to define "current envelope recipient address" as the address 
_after_ alias resolution at the final destination, ie. not the address 
seen in the SMTP conversation. Otherwise mail to [e-mail] would 
likely trigger vacation responses from all absent team members.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43M0Zi3089240; Tue, 3 May 2005 15:00:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43M0Zih089239; Tue, 3 May 2005 15:00:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43M0XoT089212 for <[e-mail]>; Tue, 3 May 2005 15:00:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DT5RH-0007YT-Tb; Wed, 04 May 2005 00:00:24 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DT5RD-0000Hy-3W; Wed, 04 May 2005 00:00:19 +0200
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Philip Guenther <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 04 May 2005 00:00:07 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.854, required 12, autolearn=disabled, AWL 2.10, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-05-03 at 12:37 -0400, Mark E. Mallett wrote:
> On Sun, May 01, 2005 at 06:27:14PM -0700, Philip Guenther wrote:
> > An implementation that wanted to support it could enable capturing
> > from 'body' matches into variables using another extension...
> 
> Yikes.  My vote is still to allow the match results to be set from a
> body test; requiring another extension just to do that seems like
> planning for a patch to correct the lack of it.  As always, that's just
> MHO; I don't really understand why setting the match result is not
> wanted.  What's the reason for forbidding it?  As I say, it's unfriendly
> to a general match implementation.  If it's a matter of protecting
> against huge match strings, I'd rather see some pragmatic limits (as I
> said in the thread previously, along with other bits about pragmatic
> limits on body testing).

indeed the variables draft includes this text which was meant to cover
this issue:

6.  Implementation Limits
   
   An implementation of this draft MUST support at least 128 distinct
   variables.  The supported length of variable names MUST be at least
   32 characters.  Each variable MUST be able to hold at least 4000
   characters.  Attempts to set the variable to a value larger than what
   the implementation supports SHOULD be reported as an error at
   compile-time if possible.  If the attempt is discovered during run-
   time, the value SHOULD be truncated and it MUST NOT be treated as an
   error.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43J2OHe059049; Tue, 3 May 2005 12:02:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43J2O2l059048; Tue, 3 May 2005 12:02:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43J2Lo2059038 for <[e-mail]>; Tue, 3 May 2005 12:02:23 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 64592 invoked by uid 101); 3 May 2005 15:02:20 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 3 May 2005 15:02:20 -0400
To: [e-mail]
Cc: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: vacation and envelope-to: another try
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.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, May 03, 2005 at 11:42:16AM -0700, [e-mail] wrote:
> > I'm not sure why this was controversial the last time, but I'm hoping
> > it was only the way I said it and not what I was saying.  If this
> > is still a bad suggestion for some reason, I'd like to hear why..
> 
> It was controversial because you suggested replacing knowledge of the
> recipient's address with simply using the current envelope recipient address. I
> don't think encouraging implementations to rely solely on envelope recipient
> address information is a good idea.

I haven't changed what I was suggesting at all, at least not in my mind.
Sorry if it was not clear the first time; if it's better this time, I'm
glad.


> I have no problem calling out that the current envelope recipient address
> as an additional source of information for this check. I'll add text to
> this effect to the revision.

Cool.

Yours,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43IulEX058158; Tue, 3 May 2005 11:56:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43IulW5058157; Tue, 3 May 2005 11:56:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43IukgI058143 for <[e-mail]>; Tue, 3 May 2005 11:56:46 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 03 May 2005 11:56:43 -0700 (PDT)
Cc: [e-mail]
Date: Tue, 03 May 2005 11:42:16 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Tue, 03 May 2005 14:07:47 -0400" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: vacation and envelope-to: another try
To: Mark E Mallett <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi-

> I wanted to bring this one point up again since I failed so miserably at
> it the last time.  So another try:


> 3.5  Address Parameter and Limiting Replies to Personal Messages

>    > "Vacation" MUST NOT respond to a message unless the user's email
>    > address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
>    > "Resent-Bcc" line of the original message.  Implementations are
>    > assumed to know the user's email address, but users may have
>    > additional addresses beyond the control of the local mail system.

> I'd like to add that the envelope recipient address, if available,
> qualifies as a known address.  In some other words:

>    "Vacation" MUST NOT respond to a message unless a valid email address
>    for the recipient appears in a "To", "Cc", "Bcc", "Resent-To",
>    "Resent-Cc", or "Resent-Bcc" line of the original message.  An email
>    address is valid for the recipient only if it is one of: an email
>    address known by the implementation to belong to the recipient; the
>    envelope recipient address if it's available to the implementation;
>    any other address specified by the script writer via the ":addresses"
>    tagged option.

> The point being that the envelope recipient address is valid for the
> recipient (since the receiving system obviously has delivered it to the
> script), and (in the spirit of RFC3834) its presence in one of those
> headers should validate the incoming message as an individually directed
> message that can be autoresponded to.  A script writer shouldn't have to
> list all possible valid envelope recipient addresses in :addresses when
> they have, in effect, been listed algorithmically.

> Perhaps this is assumed to be covered by "implementations are assumed to
> know the user's email address" but I would not read that sentence that
> way and I wouldn't expect other readers of the RFC to make that leap.

> I'm not sure why this was controversial the last time, but I'm hoping
> it was only the way I said it and not what I was saying.  If this
> is still a bad suggestion for some reason, I'd like to hear why..

It was controversial because you suggested replacing knowledge of the
recipient's address with simply using the current envelope recipient address. I
don't think encouraging implementations to rely solely on envelope recipient
address information is a good idea.

I have no problem calling out that the current envelope recipient address
as an additional source of information for this check. I'll add text to
this effect to the revision.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43I7rjr050873; Tue, 3 May 2005 11:07:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43I7rHI050872; Tue, 3 May 2005 11:07:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43I7pFc050850 for <[e-mail]>; Tue, 3 May 2005 11:07:52 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 79059 invoked by uid 101); 3 May 2005 14:07:47 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 3 May 2005 14:07:47 -0400
To: [e-mail]
Subject: vacation and envelope-to: another try
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Hi-

I wanted to bring this one point up again since I failed so miserably at
it the last time.  So another try:


3.5  Address Parameter and Limiting Replies to Personal Messages

   > "Vacation" MUST NOT respond to a message unless the user's email
   > address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   > "Resent-Bcc" line of the original message.  Implementations are
   > assumed to know the user's email address, but users may have
   > additional addresses beyond the control of the local mail system.

I'd like to add that the envelope recipient address, if available,
qualifies as a known address.  In some other words:

   "Vacation" MUST NOT respond to a message unless a valid email address
   for the recipient appears in a "To", "Cc", "Bcc", "Resent-To",
   "Resent-Cc", or "Resent-Bcc" line of the original message.  An email
   address is valid for the recipient only if it is one of: an email
   address known by the implementation to belong to the recipient; the
   envelope recipient address if it's available to the implementation;
   any other address specified by the script writer via the ":addresses"
   tagged option.

The point being that the envelope recipient address is valid for the
recipient (since the receiving system obviously has delivered it to the
script), and (in the spirit of RFC3834) its presence in one of those
headers should validate the incoming message as an individually directed
message that can be autoresponded to.  A script writer shouldn't have to
list all possible valid envelope recipient addresses in :addresses when
they have, in effect, been listed algorithmically.

Perhaps this is assumed to be covered by "implementations are assumed to
know the user's email address" but I would not read that sentence that
way and I wouldn't expect other readers of the RFC to make that leap.

I'm not sure why this was controversial the last time, but I'm hoping
it was only the way I said it and not what I was saying.  If this
is still a bad suggestion for some reason, I'd like to hear why..

Yours,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43GltUM037958; Tue, 3 May 2005 09:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43Glt8K037957; Tue, 3 May 2005 09:47:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43Gls60037941 for <[e-mail]>; Tue, 3 May 2005 09:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 54431 invoked by uid 101); 3 May 2005 12:47:54 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 3 May 2005 12:47:54 -0400
To: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
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.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, May 02, 2005 at 10:31:30AM -0400, Cyrus Daboo wrote:
> Hi Philip,
> 
> --On May 1, 2005 9:35:04 PM -0700 Philip Guenther 
> <[e-mail]> wrote:
> 
> >>FWIW, I miss it too.
> >
> >I'm not enthralled by the idea of bringing replaceheader back into
> >the draft at this late date, especially given how the complexity
> >issues were never resolved.  I somehow suspect that the ensuing
> >discussion would be a cut-and-paste of the one that took place two
> >years ago.
> >
> >Therefore, I am pushing back on these wistful thoughts.
> >
> 
> In the interests of getting editheader finished soon, I agree with this 
> approach, but I would like to hear from anyone who thinks replaceheader 
> really must be present (of course we can add it as an extension at some 
> later point if sufficient demand does arise later).

To me, it's "pick your evil."  One adds to the proliferation of
extensions, and separates things that really should be together.  The
other delays the standardization of 2/3 of those things.  Me, I'd vote
for the delay, especially considering that we can probably predict that
the "addheader/deleteheader" syntax is pretty well settled and it's not
much of a risk for people to start using that part of the extension.
e.g. I wonder how many implementations already include an "editheader"
extension that is being used despite not being standardized...

But I wouldn't be too upset about it going the other way, either.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43Gbf9S036604; Tue, 3 May 2005 09:37:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43GbfuE036603; Tue, 3 May 2005 09:37:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43GbdHg036597 for <[e-mail]>; Tue, 3 May 2005 09:37:39 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 45141 invoked by uid 101); 3 May 2005 12:37:39 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 3 May 2005 12:37:39 -0400
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt
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.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 Sun, May 01, 2005 at 06:27:14PM -0700, Philip Guenther wrote:
> 
> >Mark E. Mallett wrote:
> >
> >>4.2 Body Transform ":content"
> >>
> >>   > The search for MIME parts matching the :content specification is
> >>   > recursive and automatically descends into multipart and
> >>   > message/rfc822 MIME parts.  Once a MIME part has been identified
> >>   > as suitable for searching, only its direct contents are searched
> >>   > for the key strings.
> >>
> >>If a message contains more than one testable part, I assume that the
> >>"body" result is the OR of the tests of all of them,
> ...
> >>This may seem obvious but it probably needs to be made explicit, no?
> 
> 
> Yeah.  To clarify, I've replaced the second/last sentence of that
> paragraph with:
> 	All MIME parts with matching types are searched for the key
> 	strings.

That doesn't actually do the clarification, though.  The question was
whether the search result is the OR of all the tests, or the AND of all
the tests.  That is, does a match in just one of the candidate parts
satisfy the test, or does the match have to appear in *all* of the
candidate parts.  What I said was that the former seems obvious to me,
but what seems obvious to one person may not be obvious to another, may
not be what was intended, and in any case probably should be said
explicitly.



> >>with a short-circuit exit.
> >>i.e., first match causes the body test to end and
> >>return a true result, whereas a non-match causes the body test to
> >>contine on to the next candidate mime part.
> 
> I don't see why short-circuiting needs to be mentioned, as it's
> simply an obvious optimization and has no effect on the visibile
> behavior.

It follows from the question of whether the match is OR or AND.  But
right, as long as that item is clarified, short-circuiting may not
have to be mentioned.



> >>5. Interaction with Other Sieve Extensions
> >>
> >>   > Regular and wildcard expressions used with "body" are exempt
> >>   > from the side effects described in [VARIABLES].  That is, they
> >>   > do not set numbered variables ${1}, ${2}... to the input
> >>   > values corresponding to wild card sequences in the matched
> >>   > pattern.
> >>
> >>I remember that this came up last fall, expressed this way:
> >>
> >>  >  QUESTION: Is it okay to have body :matches and
> >>  >  :regex scans not set variables?
> >>
> >>and the (small) concensus was a "yes" answer to that question.  I took
> >>that to mean that people thought it was OK for an implementation not to
> >>set the numbered variables-- not that an implementation would be
> >>prohibited from doing so.  This prohibition is unfriendly to
> >>general-purpose match logic.
> 
> An implementation that wanted to support it could enable capturing
> from 'body' matches into variables using another extension...

Yikes.  My vote is still to allow the match results to be set from a
body test; requiring another extension just to do that seems like
planning for a patch to correct the lack of it.  As always, that's just
MHO; I don't really understand why setting the match result is not
wanted.  What's the reason for forbidding it?  As I say, it's unfriendly
to a general match implementation.  If it's a matter of protecting
against huge match strings, I'd rather see some pragmatic limits (as I
said in the thread previously, along with other bits about pragmatic
limits on body testing).

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43GNd7k034294; Tue, 3 May 2005 09:23:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43GNdDi034293; Tue, 3 May 2005 09:23:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43GNceD034286 for <[e-mail]>; Tue, 3 May 2005 09:23:38 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 42410 invoked by uid 101); 3 May 2005 12:23:37 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 3 May 2005 12:23:37 -0400
To: [e-mail]
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 29, 2005 at 04:57:02PM -0700, Matthew Elvey wrote:
> [e-mail] sent forth electrons to *convey (among other 
> things) an interesting point*:
> 
> >...
> >I really don't want to do anything that has the potential to make 
> >reject more
> >popular than it already is.
> 
> Ok, I think you have a valid argument here.  Why cause trouble enhancing 
> something we're trying to render as obsolete and rarely used as possible?
> Ok, so we'll leave reject as is, and refuse as is? (the latter works 
> with "reject" and "discard", but the former doesn't.)

I still favor trying to overload "refuse" onto "reject" (so that the
implementation will interpret "reject" as "refuse" where possible,
maybe with the addition of optional tags that allow the script writer
to guide the behaviour) rather than introducing a new "refuse" keyword.
Or at least talking about it more.  But I suppose that's for the
"refuse" discussion.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43CioKD098754; Tue, 3 May 2005 05:44:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j43CioiS098753; Tue, 3 May 2005 05:44:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43CimYI098726 for <[e-mail]>; Tue, 3 May 2005 05:44:49 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Tue, 3 May 2005 14:51:19 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
Cc: Philip Guenther <[e-mail]>
References: <[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>

Philip Guenther writes:
> Arnt Gulbrandsen wrote:
>> Another minor point: If a message is rejected after being modified, 
>> which version of the message should be sent to the bounce address, 
>> the original message or the one with a modified header?
>
> The one with the modified header. This was covered by the "Actions 
> that create messages..." sentence in section 5, which I'm changing to 
> the "Actions that store or send the message..." sentence mentioned 
> above.

Fine with me.

Please note specifically that addheader/refuse won't use the modified 
message, though. (Yes, I realize that for all known current 
implementations, addheader/refuse isn't possible in the first place.)

It could be (I don't know, nor really care) that you should mention that 
addheader/reject in that order could expose information unintended, so 
users should be careful where appropriate.

> Now for the two ugly issues:
>
> Ned Freed wrote:
>> I think we need weasel words to the effect that changing the meaning 
>> of the MIME structure with addheader may not produce results that 
>> actually affect subsequent body or other MIME-related tests.
>
> (Also commented on by Arnt Gulbrandsen and William Leibzon)
>
> Does the following, added after the first example in section 5, give 
> the correct dose of leeway?

Yes.

I'm not entirely happy that people can change message-id et al, but I 
don't think it's a big deal either. Some people always find means to 
shoot their lower extremities, and giving them one more doesn't really 
matter.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42HwuXX070630; Mon, 2 May 2005 10:58:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j42Hwu1l070629; Mon, 2 May 2005 10:58:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42HwtW2070623 for <[e-mail]>; Mon, 2 May 2005 10:58:55 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j42HwqdO022536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 2 May 2005 10:58:52 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j42HwqdO022536
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=pz00O5/dp3Y7BdsIf7sb+blr/rzcHa/qtykUGPZ9l4lzxyWbK2RYhactyYRcDqg8M 3f+nY0WStZyee2aNNGTmbRaH0mlB+hoyZ6Hjinv53MIjmYviYzTpbU5px9gNg8C2wiT Lw+uweJvEtDhnqy/nRKDMb7ZMqnijLrLSVrUGpQ=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j42Hwqau072732; Mon, 2 May 2005 10:58:52 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
From: Philip Guenther <[e-mail]>
cc: [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Mon, 02 May 2005 10:58:52 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo <[e-mail]> writes:
>Philip Guenther <[e-mail]> wrote:
...
>> Therefore, I am pushing back on these wistful thoughts.
>
>In the interests of getting editheader finished soon, I agree with this 
>approach, but I would like to hear from anyone who thinks replaceheader 
>really must be present (of course we can add it as an extension at some 
>later point if sufficient demand does arise later).

For those who may have lost track of the discussion that led to
replaceheader being dropped, the relevant thread in the archives can be
found at:
    http://www.imc.org/ietf-mta-filters/mail-archive/msg01276.html

where it starts with Jutta's initial announcement of the editheader (and
copy and multiscript) drafts.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42HGIPU063236; Mon, 2 May 2005 10:16:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j42HGI9p063235; Mon, 2 May 2005 10:16:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42HGITU063220 for <[e-mail]>; Mon, 2 May 2005 10:16:18 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j42HGFgs011138 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 2 May 2005 10:16:15 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j42HGFgs011138
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=fqgtldnVNmYThCoc+pKrEJndO2293TlmCe2dKd5ECKM6TK4ei12/qq6zeD64byN0C NeFzzRPcvv1N+DYoRCBjCZnXKBtX6oa/vfhh/KU0sxI3IVYDz66tnI6L9+BE32socX0 FpMb5p2dCnEQ22nx7P54rTF1gfCniCwnvKJiOr0=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j42HGFSK068645; Mon, 2 May 2005 10:16:15 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Nigel Swinson <[e-mail]>
From: Philip Guenther <[e-mail]>
cc: [e-mail]
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt 
In-reply-to: <006301c54ef8$0f4a4a30$6501a8c0@nigelhome> 
References: <[e-mail]> <[e-mail]>  <006301c54ef8$0f4a4a30$6501a8c0@nigelhome> 
Date: Mon, 02 May 2005 10:16:15 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson <[e-mail]> writes:
...
>>    If the :content specification matches a multipart MIME part,
>
>-    only the prologue and epilogue sections of the will be searched
>+   only the prologue and epilogue sections of the body part will be searched
>
>>    for the key strings; the contents of nested parts are only
>>    searched if their respective types match the :content specification.

Hmm, how about:
    If the :content specification matches a multipart MIME part,
    only the prologue and epilogue sections of the part will be
    searched for the key strings; <...>

(i.e., dropping the 'body' from your suggestion).


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EVlKF040405; Mon, 2 May 2005 07:31:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j42EVli4040404; Mon, 2 May 2005 07:31:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EViBR040383 for <[e-mail]>; Mon, 2 May 2005 07:31:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.4] (pool-141-151-187-231.pitt.east.verizon.net [141.151.187.231]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j42EAs6g013348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2005 10:10:59 -0400
Date: Mon, 02 May 2005 10:31:30 -0400
From: Cyrus Daboo <[e-mail]>
To: Philip Guenther <[e-mail]>, [e-mail]
Subject: Re: Responses to comments on draft-ietf-sieve-editheader-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Philip,

--On May 1, 2005 9:35:04 PM -0700 Philip Guenther 
<[e-mail]> wrote:

>> FWIW, I miss it too.
>
> I'm not enthralled by the idea of bringing replaceheader back into
> the draft at this late date, especially given how the complexity
> issues were never resolved.  I somehow suspect that the ensuing
> discussion would be a cut-and-paste of the one that took place two
> years ago.
>
> Therefore, I am pushing back on these wistful thoughts.
>

In the interests of getting editheader finished soon, I agree with this 
approach, but I would like to hear from anyone who thinks replaceheader 
really must be present (of course we can add it as an extension at some 
later point if sufficient demand does arise later).

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j429JXOZ033382; Mon, 2 May 2005 02:19:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j429JXPY033381; Mon, 2 May 2005 02:19:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j429JXbI033339 for <[e-mail]>; Mon, 2 May 2005 02:19:33 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.203]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Mon, 2 May 2005 02:19:28 -0700
Message-ID: <006301c54ef8$0f4a4a30$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Philip Guenther" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>  <[e-mail]>
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt 
Date: Mon, 2 May 2005 10:19:34 +0100
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j429JXbI033375
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 clarify the matching against multipart and message/rfc822 parts,
> I've replaced that paragraph with:
> 
>    If the :content specification matches a multipart MIME part,

-    only the prologue and epilogue sections of the will be searched
+   only the prologue and epilogue sections of the body part will be searched

>    for the key strings; the contents of nested parts are only
>    searched if their respective types match the :content specification.

:o)

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j424Z7NT014614; Sun, 1 May 2005 21:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j424Z7fe014613; Sun, 1 May 2005 21:35:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j424Z5vo014604 for <[e-mail]>; Sun, 1 May 2005 21:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j424Z4cJ022394 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Sun, 1 May 2005 21:35:05 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j424Z4cJ022394
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=oawWhKyKwbeHzJ0eM6KQL4Lxh1aDS0SqpTEMvVeksAHsxeCkRNcOJm4ykHEErmbID dwguLmAHpfW9KGXNRLQUIAM20uYc8vj8LF3pJw2QVPkPkwZZQeuJNmqKle3h/djJAQ6 wOCvUONpXcnfsaL6ezx+/0S/FX/8RaJFLRxVDbI=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j424Z4qL003108 for <[e-mail]>; Sun, 1 May 2005 21:35:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Responses to comments on draft-ietf-sieve-editheader-00.txt
Date: Sun, 01 May 2005 21:35:04 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Again, my apologies to the working group for the long delay in 
responding to the comments from the WGLC on this draft.  

I'm not going to list the trivial editorial changes here.


Matthew Elvey wrote:
>>   Tests and actions such as "exist" or "header" that examine
>
>The test is "exists", not "exist".  "Exists" and "header" are both
>tests, and actions don't examine.  Therefore, I suggest:
>       Tests such as "exists" or "header" that examine

Instead of restricting it to tests, I've added an action that
examines header fields:
   Tests and actions such as "exists", "header", or "vacation"
   [VACATION] that examine header fields MUST examine the current
   state of a header as modified by any actions that have taken
   place so far.


Mark E. Mallett wrote:
>>   use of [KEYWORDS] and "Syntax:" label for the definition of action
>
>I think labels are plural, so it ought to read "... labels for
>definitions of ..."

Not quite: the correct parse groups from "Syntax:" to the end of
the sentence.  Inserting a 'the' clears it up, I think:
   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS] and the "Syntax:" label for the definition of
   action and tagged arguments syntax.

(I.e., the conventions include "use of [KEYWORDS]" and "use of the
Syntax: label for...syntax")


>Just the obligatory comment about using "example.tld" even though "tld"
>isn't a real top level domain name today.

I've changed "foo.tld" to "foo.example.com":
        if not header :contains "X-Sieve-Filtered"
                ["<[e-mail]>", "<[e-mail]>"]
        {
                addheader "X-Sieve-Filtered" "<[e-mail]>";
                redirect "[e-mail]";
        }


>Should there be remarks about the potential damage that can be
>caused to the MIME structure of a message (e.g. by removing/adding
>MIME header fields)?

With regards to the effect this can have on the sieve processing
itself, see below.  Or were you suggesting a "this tool is sharp:
poking self in eye may harm depth preception" warning?



Nigel Swinson wrote:
>Is it worth making it explicit that if deleteheader can't find any
>matching headers then this isn't an error?

I've added the following as the last paragraph of section 4:
   It is not an error if no header fields match the conditions in
   the deleteheader action or if the :index argument is greater
   than the number of named header fields.


>I think we are saying that editheader does not cancel the implict
>keep (certainly this makes sense), but I don't think we've been
>very clear about it.  I liked the clarity of what was said in the
>vacation draft: "Vacation does not affect Sieve's implicit keep
>action."

I've added "The addheader action does not affect Sieve's implicit
keep." to section 3 and a similar statement for deleteheader to
section 4.


Cyrus Daboo wrote:
>4.5: replace ';' at end of paragraph with '.'. Add 'Example:' as    
>new line after paragraph.

Given the text following the example, I went with:

			      <...>  The counting happens
   before the <value-patterns> match, if any.  For example:

        deleteheader :index 2 :contains "Received" "via carrier-pigeon"

   deletes the second "Received:" header field if it contains
   <...>


Alexey Melnikov wrote:
>>   Actions that create messages in storage or in transport to
>>   MTAs MUST store and send messages with the current set of
>>   header fields.
>                        
>I am not sure I understand what is "in transport to MTAs", is this
>trying to say "in MTA's queue"?

It's trying to say that if you do something like forward the message,
the forwarded content reflects any changes.  Would it be clearer
if that sentence was simplified to

   Actions that store or send the message MUST do so with the
   current set of header fields.

?


>>   MUST only file one message.  It is up to the implementation
>>   to pick which of the redundant "fileinto" or "keep" actions is
>>   executed, and which ones are ignored.
>
>I am not sure I like this, even though I understand the motivation.
>When Ned and Ken has discussed imapflags they agreed that the last
>keep wins (i.e. the current flags at the time of the last keep).
>Consistency is a good thing.  And the MUST at the beginning of
>section 5 seems to suggest the same.

I just reviewed the discussion on the from when it was changed to
this and the thought from at least a couple people at the time was
that leaving it open would ease implementation by making it agnostic
to the "evaluate as you go" vs "evaluate all at the end" choice.
Is there consensus to change this again?

(Previous to that, it called for *no* duplicate supression.)


Arnt Gulbrandsen wrote:
>Another minor point: If a message is rejected after being modified,
>which version of the message should be sent to the bounce address,
>the original message or the one with a modified header?

The one with the modified header.  This was covered by the "Actions
that create messages..." sentence in section 5, which I'm changing
to the "Actions that store or send the message..." sentence mentioned
above.



Now for the two ugly issues:

Ned Freed wrote:
>I think we need weasel words to the effect that changing the meaning 
>of the MIME structure with addheader may not produce results that
>actually affect subsequent body or other MIME-related tests.

(Also commented on by Arnt Gulbrandsen and William Leibzon)

Does the following, added after the first example in section 5,
give the correct dose of leeway?

   However, if the presence or value of a header field affects how
   the implementation parses or decodes other parts of the message,
   then for the purposes of that parsing or decoding the implementation
   MAY ignore some or all changes made to those header fields.  For
   example, in an implementation that supports the [BODY] extension,
   "body" tests may be unaffected by deleting or adding Content-Type
   or Content-Transfer-Encoding header fields.  This does not rescind
   the requirement that changes to those header fields affect direct
   tests; only the semantic side effects of changes to the fields
   may be ignored.

If not, where did I miss the turn?


Ned Freed wrote:
>>[Mark Mallett wrote:]
>> I really miss "replaceheader" and I think it's a huge mistake not to
>> include it.  "replaceheader" was the only way that one could rename a
>> header in place, which may have been one source of the objections to it,
>> but which I found to be the root of its value.  Perhaps a compromise
>> could be to include "replaceheader" as an optional additional capability
>> name in this document (the way that "fileinto" is included in the base
>> spec).
>
>FWIW, I miss it too.

I'm not enthralled by the idea of bringing replaceheader back into
the draft at this late date, especially given how the complexity
issues were never resolved.  I somehow suspect that the ensuing
discussion would be a cut-and-paste of the one that took place two
years ago.

Therefore, I am pushing back on these wistful thoughts.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j421RHv5090855; Sun, 1 May 2005 18:27:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j421RHOD090854; Sun, 1 May 2005 18:27:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j421RF5H090846 for <[e-mail]>; Sun, 1 May 2005 18:27:17 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j421RE9h012130 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Sun, 1 May 2005 18:27:14 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j421RE9h012130
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Ty8YtGfxOGPspm38mRXQ2oexUjgPLWVO8yjIhEWsUsVtDvuLM6lm0TusNOKeyaRvs Yo08WGoBQ848H1JbMC+7ayKcN3nr6bh3Ym2Bxrk4xhDLiERXT5bly2MvHgZYJw2P+IU 1zkzYmjOzd2v5Ng/Wx7nAxAcV2kl1HblLjgYp50=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j421REDY086939 for <[e-mail]>; Sun, 1 May 2005 18:27:14 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: Collected comments for draft-ietf-sieve-body-00.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Sun, 01 May 2005 18:27:14 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My apologies to the working group for the long delay in responding
to the comments from the WGLC on the body and editheader drafts.
My thanks to the chairs for compiling the comments; here are my
responses for the body draft.


>Ken Murchison wrote:
>> Section 4.1, paragraph 2, last phrase says "... and MUST NOT interpret 
>> or skip MIME headers of enclosed body parts."
>>
>> I don't think that the intent was to have "MUST NOT" refer to "skip", 
>> but it reads that way.  I'd recommend that either "or skip" be removed 
>> (since not interpreting them seems to encompass ignoring them), or 
>> reword the entire phrase to something like:  "... and either MUST NOT 
>> interpret MIME headers of enclosed body parts or MUST ignore them 
>> entirely."

The intent is that under the :raw transformation, the message is
just a series of octets with no special interpretation.  MIME headers
in enclosed body parts are therefore just more pieces of text to
match against.  To make that clearer, I've changed the last clause of
that sentence to read:

   <...> and MUST treat multipart boundaries
   or the MIME headers of enclosed body parts as part of the text
   being matched against instead of as MIME structures to interpret.


>Bob Johannessen wrote:
>
>>4.1 Body Transform ":raw"
>>
>>      # This will match a message containing the words "MAKE MONEY FAST"
>>      # in body or MIME headers other than the outermost RFC 822 header,
>>      # but will not match a message containing the words in a
>>      # content-transfer-encoded body.
>>
>>Wouldn't it be more correct to say that it matches the string, or
>>even the character sequence "MAKE MONEY FAST"? Also I'm not sure I
>>understand what is meant by "a content-transfer-encoded body". It
>>*could* still match the character sequence in a quoted-printable
>>encoded body, couldn't it?

Correct.  I've changed to comment to read:

	# This will match a message containing the literal text
	# "MAKE MONEY FAST" in body parts (ignoring any 
	# content-transfer-encodings) or MIME headers other than    
	# the outermost RFC 2822 header.


>>4.2 Body Transform ":content"
>>
>>   If an implementation does not support conversion of a given
>>   charset to  UTF-8, it MAY compare against the US-ASCII subset
>>   of the transfer-decoded character data instead.
>>
>>Does the above rely on all current and future charsets having
>>a one-to-one mapping to US-ASCII for all characters with code
>>points 0-127? Is this a safe assumption? Is it even true of all
>>existing charsets? Maybe it would be better to explicitly
>>exclude all parts who can't be converted to UTF-8?

On reflection, I think this was intended to be similar to the
requirements of section 2.7.2 ("Comparisons Across Character Sets")
of the base-spec, but slightly stricter in that implementations
would be required to support UTF-8.


Speaking of which, perhaps that section of the base-spec should be
updated to require support of UTF-8 for header charsets, only falling
back to the weaker "No two strings..." text for charsets other than
UTF-8.


If that change was made, then I think the problem paragraph in the
body draft could be replaced with
	Implementations MUST use the same rules for comparisons
	against body parts in charsets other than UTF-8 as they use
	for comparisons against header fields in such charsets (c.f.
	[SIEVE] section 2.7.2).

(and the SIEVE reference would need to be updated to be against the
revision)


>Mark E. Mallett wrote:
>
>>4.2 Body Transform ":content"
>>
>>   > The search for MIME parts matching the :content specification is
>>   > recursive and automatically descends into multipart and
>>   > message/rfc822 MIME parts.  Once a MIME part has been identified
>>   > as suitable for searching, only its direct contents are searched
>>   > for the key strings.
>>
>>If a message contains more than one testable part, I assume that the
>>"body" result is the OR of the tests of all of them,
...
>>This may seem obvious but it probably needs to be made explicit, no?


Yeah.  To clarify, I've replaced the second/last sentence of that
paragraph with:
	All MIME parts with matching types are searched for the key
	strings.


>>with a short-circuit exit.
>>i.e., first match causes the body test to end and
>>return a true result, whereas a non-match causes the body test to
>>contine on to the next candidate mime part.

I don't see why short-circuiting needs to be mentioned, as it's
simply an obvious optimization and has no effect on the visibile
behavior.  While the base spec does encourage implementation to
implement short-circuiting in evaluation of string lists, it didn't
seem necessary to mention that they should stop searching within a
header/address/whatever for a given string as soon as a match is
found.


>[...]
>>   > For example, a document with "multipart" major content type only
>>   > directly contains the text in its epilogue and prologue section;
>>   > all the user-visible data inside it is directly contained in
>>   > documents with MIME types other than multipart.
>>
>>I question the term "user-visible."  I'm a user, and the prolog and
>>epilog stuff is always visible to me in my mail reader.  Maybe just
>>say "other" ?

To clarify the matching against multipart and message/rfc822 parts,
I've replaced that paragraph with:

   If the :content specification matches a multipart MIME part,
   only the prologue and epilogue sections of the will be searched
   for the key strings; the contents of nested parts are only
   searched if their respective types match the :content specification.

   If the :content specification matches a message/rfc822 MIME part,
   only the header of the nested message will be searched for the
   key strings; the contents of the nested message body parts are  
   only searched if its content-type matches the :content specification.

and have dropped the "Nevertheless" from the following parenthetical
remark.

Furthermore, I've inserted an elaborate example of these rules,
building from Cyrus's suggestion, described below.


...
>"words" not "worlds"
...
>>My name jumped out at me- if it's in there, it should be
>>spelled "Mallett"  :-)

Fixed and fixed.


>>5. Interaction with Other Sieve Extensions
>>
>>   > Regular and wildcard expressions used with "body" are exempt
>>   > from the side effects described in [VARIABLES].  That is, they
>>   > do not set numbered variables ${1}, ${2}... to the input
>>   > values corresponding to wild card sequences in the matched
>>   > pattern.
>>
>>I remember that this came up last fall, expressed this way:
>>
>>  >  QUESTION: Is it okay to have body :matches and
>>  >  :regex scans not set variables?
>>
>>and the (small) concensus was a "yes" answer to that question.  I took
>>that to mean that people thought it was OK for an implementation not to
>>set the numbered variables-- not that an implementation would be
>>prohibited from doing so.  This prohibition is unfriendly to
>>general-purpose match logic.

An implementation that wanted to support it could enable capturing
from 'body' matches into variables using another extension...


>>Also, if it is a prohibition, shouldn't
>>"MUST NOT" appear there?

   Regular and wildcard expressions used with "body" are exempt  
   from the side effects described in [VARIABLES].  That is, they
   MUST NOT set numbered variables ${1}, ${2}... to the input values
   corresponding to wild card sequences in the matched pattern.
   However, if the extension is present, variable references in the   
   key strings or content type strings are evaluated as described
   in the draft.

(That takes into account a suggestion from Nigel Swinson as well).


>Nigel Swinson wrote:
>>7. Security Considerations
>>I suggest:
>>-   replacement for a virus or spam filtering system.
>>+  replacement for a spam, virus or other security related filtering system.

Done.


>Cyrus Daboo wrote:
>> --On March 28, 2005 15:36:30 +0100 Nigel Swinson 
<...comments on the lack of clarity in matching multipart
types and a suggestion of an example...>

I've inserted the following example into section 4.2:
-----
   Example:
        From: Whomever
        To: Someone
        Date: Whenever
        Subject: whatever
        Content-Type: multipart/mixed; boundary=outer

     &  This is a multi-part message in MIME format.
     &
        --outer
        Content-Type: multipart/alternative; boundary=inner

     &  This is a nested multi-part message in MIME format.
     &
        --inner
        Content-Type: text/plain; charset="us-ascii"

     $  Hello
     $
        --inner
        Content-Type: text/html; charset="us-ascii"

     %  <html><body>Hello</body></html>
     %
        --inner--
     &
     &  This is the end of the inner MIME multipart.
     &
        --outer
        Content-Type: message/rfc822

     !  From: Someone Else
     !  Subject: hello request

     $  Please say Hello
     $
        --outer--
     &
     &  This is the end of the outer MIME multipart.


   In the above example, the '&', '$' and '%' characters at the
   start of a line are used to illustrate what portions of the
   example message are used in tests:

   - the lines starting with '&' are the ones that are tested when
     a 'body :content "multipart" :contains "MIME"'
     test is executed.

   - the lines starting with '$' are the ones that are tested when
     a 'body :content "text/plain" :contains "Hello"' test is
     executed.

   - the lines starting with '%' are the ones that are tested when
     a 'body :content "text/html" :contains "Hello"' test is executed.
   - the lines starting with '$' or '%' are the ones that are tested
     when a 'body :content "text" :contains "Hello"' test is executed.

   - the lines starting with '!' are the ones that are tested when
     a 'body :content "message/rfc822" :contains "Hello"' test is
     executed.
----


>Cyrus Daboo wrote:
...
>> Header: Fix alignment of 'Philip Guenther'
>> 1.3 : 'specifies it syntax' -> 'specifies its syntax'
>> 2.2 : 'with extension' -> 'with the extension'
>> 3.1 : reformat syntax
>> 3.4 : 'all "body" tests fail' -> 'all "body" tests return false'
>> 4.2 : reformat syntax
>> 4.2 : the term 'document' is used to refer to a MIME 'part', I would 
>>       prefer using 'part' in all cases.
>> Appendix B: missing reference [REGEX]

All done


>> 4.2p6 : 'decoded to prior' -> 'decoded prior'

Done.  I've added text to require support for the 7bit, 8bit, and
binary transfer encodings so that the MAY only applies to
not-yet-standardized encodings:
   MIME parts encoded in "quoted-printable" or "base64" content
   transfer encodings MUST be decoded prior to the match.  MIME
   parts in "7bit", "8bit", "binary" content transfer encodings
   MUST be matched as they are.  MIME parts in content transfer
   encodings other than those MAY be decoded, omitted from the test,
   or processed as raw data.


>> 4.3 : just for completeness add an example.

Added:
   Example:
        require ["body", "fileinto"];

        # Save messages mentioning the project schedule in the
        # project/schedule folder.
        if body :text :contains "project schedule" {
                fileinto "project/schedule";
        }


>My comments:
>
> >4.2 Body Transform ":content"
>[...]
> >   If an individual content type contains a '/' (slash), it
> >   specifies a full <type>/<subtype> pair, and matches only
> >   that specific content type.  If it is the empty string, all
> >   MIME content types are matched.  Otherwise, it specifies a
> >   <type> only, and any subtype of that type matches it.
>
>I would like to see ABNF for the content type and some text explaining 
>what should be done if the user specified an invalid value here, e.g. 
>"/". I suspect the answer to this can be: no runtime error, but no match.

I would rather not drag in ABNF just for this single paragraph.
Indeed, I suspect the result would be more difficult to comprehend
when specified that way.  As the only cases not covered by the
current text are values that begin or end with a slash or contain
multiple slashes, I've added an initial case to specify that they
match no content types:

   If an individual content type begins or ends with a '/' (slash) 
   or contains multiple slashes, it matches no content types.  
   Otherwise, if it contains a slash, then it specifies a full
   <type>/<subtype> pair, and matches only that specific content   
   type.  If it is the empty string, all MIME content types are
   matched.  Otherwise, it specifies a <type> only, and any subtype 
   of that type matches it.



At this point, I think there is only one unresolved issue: what is
required for charset conversion when using :content?  As stated
above, my preference would be to update the base spec revision's
secion 2.7.2 to require support for UTF-8, and then simply refer
to that in section 4.2 of the body I-D.

Opinions?


Philip Guenther