Subject: Re: 51st IETF - Internet Message Access Protocol Extension WG
From: Pete Resnick <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Tue, 31 Jul 2001 16:08:39 -0500
List-Id: <ietf-imapext.imc.org>

On 7/31/01 at 2:32 PM -0600, Alexey Melnikov wrote:

>What about CONDSTORE issues?

Consider it added.

>Is this the order of discussion?

Nope. Just a list. We generally figure out order when we get there.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 31 Jul 2001 14:32:01 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 51st IETF - Internet Message Access Protocol Extension WG
Sender: [email-masked]

[email-masked] wrote:

> Internet Message Access Protocol Extension WG (imapext)
>
> Monday, August 06 at 1930-2200
> ===============================
>
> CHAIR:  Pete Resnick <[email-masked]>
>
> AGENDA:
>
> - ANNOTATE issues

What about CONDSTORE issues?

> - New WINDOW proposal
> - LIST extensions
> - Status of SORT/THREAD
> - Status of ACL

Is this the order of discussion? If it is, I would rather move WINDOW to the end (because it
might take a lot of time), ACL to the beginning (because nothing was done so far with it),
LIST/SORT/THREAD to the beginning (they should be straightforward).

> The following will be discussed as time permits:
>
> - BINARY
> - The MULTIAPPEND/LITERAL+ debate
>
> Other items under discussion on the IMAPEXT mailing list may be added at the time of the m
> eeting.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Tue, 31 Jul 2001 15:21:01 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Proposal for ANNOTATEMORE extension
Sender: [email-masked]

Hi folks,
Since we're getting close to completing ANNOTATE (some issues are still
unresolved on the list), I'd like to propose an extension to add
annotations for mailboxes and the server. I'm calling this ANNOTATEMORE.

The idea with this is to allow annotations to be attached to each mailbox,
and for a set of 'global' annotations associated with the server itself.
Examples of use include a 'message of the day' server annotation, an
annotation on mailboxes indicating the default sort order to use when
displaying the mailbox to the user etc.

My proposal is to use the same entry/attribute/value data model that
ANNOTATE uses. In this case we would have /server and /mailbox/<mailbox
name> top level entries. We would have to have two new commands for reading
and writing annotations, and a new untagged response for returning the
annotation data, e.g.:

a SETANNOTATION ("/mailbox/INBOX/sort" ("value" "SUBJECT"))
a OK SETANNOTATION complete

a GETANNOTATION ("/server/motd" "value"))
* ANNOTATION ("/server/motd" ("value" "Server maintenance at 10 pm"))
a OK GETANNOTATION complete

I believe this is a logical extension to the message annotation capability
that ANNOTATE introduces, and there is already one server that has its own
equivalent of the server annotation mechanism, so it would be good to
standardise this.

I'm prepared to describe this in more detail in London next week, if we
agree to put it on the agenda.

Comments?

-- 
Cyrus Daboo

Date: Fri, 27 Jul 2001 17:52:51 -0700
From: Chris Newman <[email-masked]>
Subject: Re: MULTIAPPEND may be a mistake
To: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

If we start with a "TRANS=APPEND" extension which only permits APPEND 
commands to the same mailbox within a transaction, then my transaction 
proposal is almost identical in complexity to the MULTIAPPEND command.  We 
can add "TRANS=STORE" later if people feel it's too complex to do both IMAP 
write operations in one extension.

Rather than doing a one-off MULTIAPPEND command, let's recognize that 
MULTIAPPEND _is_ a transaction facility and should be designed as the first 
application of a transaction infrastructure in IMAP.

Transactions do get complex if they span mailboxes and support parallel 
simultaneous writes to the same mailbox, but those features can be deferred 
to a separate extension if we ever need them.

Perhaps we should call the commands:
	WRITEGROUP START
	WRITEGROUP CANCEL
	WRITEGROUP END
since I notice an irrational fear of the concept "transaction" in some 
circles.

		- Chris

--On Friday, July 27, 2001 11:41 -0700 Jutta Degener <[email-masked]> 
wrote:
> Nobody doubts that transactions would be nice to have, powerful
> transactions even nicer.  But they're not required for MULTIAPPEND,
> and they're tricky to implement in systems that don't already have them.
>
> MULTIAPPEND, since it's one command, can be handled in small systems
> by locking a mailbox, appending, and unlocking the mailbox.  As soon
> as you stretch the transaction period across multiple commands, you're
> opening a can of synchronization problems that IMAP has so far wisely
> stayed away from.
>
> Jutta <[email-masked]>
>

To: Lyndon Nerenberg <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, <[email-masked]>
Subject: Re: BINARY and CTE transformations
From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jul 2001 02:41:01 +0200
Lines: 17
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

>> Not only do you have to convert the data back to the original CTE, but you
>> must also ensure that the original MIME headers are exactly the same as
>> they were when the message was signed, including folding, case-sensitivity
>> of the CTE value etc. You'd have to find some way of encapsulating the
>> original MIME headers in the modified version to ensure this would work
>> reliably.
> 
> True enough, however I think this can be handled in a lightweight manner.
> (And it *must* be handled in a lightweight manner if this is going to
> catch on.)

Just curious, could you elaborate on the "lightweight manner"?
Servers that reformat MIME headers cause multipart/signed to break in
the real world today, so something that would solve this would surely
be appreciated, I think.

Date: Fri, 27 Jul 2001 15:24:04 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY and CTE transformations
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, July 27, 2001 15:02 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:
> But what standard is being violated? Transforming things that are signed
> or encrypted is asking for trouble, but it's not outright forbidden that
> I'm aware of.

multipart/signed applied to 8-bit and binary in any context where the 
message might go over SMTP is forbidden by RFC 1847.  I'd say the 
restriction on binary by inference applies to any 8-bit/non-binary 
transport and thus applies to IMAP.

> This issue is a major concern for us since we're generating large
> quantities of signed and encrypted content that gets sent out through
> software we have no control over. We have to assume there will be cases
> where CTE transformations *must* be applied to a message in order to
> deliver it to the end-user client software. CTE transformation is not evil
> in and of itself ... if the client can reconstitute the original CTE, and
> the CTE transformations are lossless, then the client can verify and
> decrypt the message even if it did get transformed along the way. Having a
> standardized way of discovering the original CTE is what makes this
> possible.

Yes, I think that would be an interesting approach.

		- Chris

Date: Fri, 27 Jul 2001 15:57:21 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: <[email-masked]>
Subject: Re: BINARY and CTE transformations
Sender: [email-masked]

> FYI The PGP/MIME specs (RFC2015, draft-ietf-openpgp-mime-08.txt) both state
> that signed data MUST be constrained to a 7bit CTE. The S/MIME message spec
> (RFC2633) has a similar MUST requirement, though it states this is only
> needed if the message is to go out on the internet. So technically one
> should never get multipart/signed data with a binary or 8bit CTE. In
> practice that may be different.

Okay, but my read on that is that you're required to _generate_ 7bit, but
they don't (and can't) outlaw what happens downstream. We're arguing
semantics, though :-)

> Not only do you have to convert the data back to the original CTE, but you
> must also ensure that the original MIME headers are exactly the same as
> they were when the message was signed, including folding, case-sensitivity
> of the CTE value etc. You'd have to find some way of encapsulating the
> original MIME headers in the modified version to ensure this would work
> reliably.

True enough, however I think this can be handled in a lightweight manner.
(And it *must* be handled in a lightweight manner if this is going to
catch on.)

--lyndon

Date: Fri, 27 Jul 2001 17:33:07 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY and CTE transformations
Sender: [email-masked]

--On Friday, July 27, 2001 3:02 PM -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> But what standard is being violated? Transforming things that are signed
> or encrypted is asking for trouble, but it's not outright forbidden that
> I'm aware of.

FYI The PGP/MIME specs (RFC2015, draft-ietf-openpgp-mime-08.txt) both state 
that signed data MUST be constrained to a 7bit CTE. The S/MIME message spec 
(RFC2633) has a similar MUST requirement, though it states this is only 
needed if the message is to go out on the internet. So technically one 
should never get multipart/signed data with a binary or 8bit CTE. In 
practice that may be different.

> This issue is a major concern for us since we're generating large
> quantities of signed and encrypted content that gets sent out through
> software we have no control over. We have to assume there will be cases
> where CTE transformations *must* be applied to a message in order to
> deliver it to the end-user client software. CTE transformation is not evil
> in and of itself ... if the client can reconstitute the original CTE, and
> the CTE transformations are lossless, then the client can verify and
> decrypt the message even if it did get transformed along the way. Having a
> standardized way of discovering the original CTE is what makes this
> possible.

Not only do you have to convert the data back to the original CTE, but you 
must also ensure that the original MIME headers are exactly the same as 
they were when the message was signed, including folding, case-sensitivity 
of the CTE value etc. You'd have to find some way of encapsulating the 
original MIME headers in the modified version to ensure this would work 
reliably.

-- 
Cyrus Daboo

Date: Fri, 27 Jul 2001 15:02:13 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: <[email-masked]>
Subject: BINARY and CTE transformations
Sender: [email-masked]

On Fri, 27 Jul 2001, Chris Newman wrote:

> I guess I can live with that, but please consider putting in some "servers
> MAY reject" language.  There are two camps in the IETF: "servers should
> enforce standards aggressively on interactive connections to deter
> standards creep" and "garbage in, garbage out".  There are server
> implementors in the former camp who will reject APPENDed messages which
> violate standards egregiously, so one may as well give the client
> implementors fair warning.

But what standard is being violated? Transforming things that are signed
or encrypted is asking for trouble, but it's not outright forbidden that
I'm aware of.

This issue is a major concern for us since we're generating large
quantities of signed and encrypted content that gets sent out through
software we have no control over. We have to assume there will be cases
where CTE transformations *must* be applied to a message in order to
deliver it to the end-user client software. CTE transformation is not evil
in and of itself ... if the client can reconstitute the original CTE, and
the CTE transformations are lossless, then the client can verify and
decrypt the message even if it did get transformed along the way. Having a
standardized way of discovering the original CTE is what makes this
possible.

If anyone wants to discuss this in London, drop me a note.

--lyndon

From: Steve Hole <[email-masked]>
Date: Fri, 27 Jul 2001 14:20:17 -0600
To: Lyndon Nerenberg <[email-masked]>
Subject: Re: BINARY version 3
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 27 Jul 2001 11:45:53 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> > (3) In section 5.4, I'd add: If an APPEND command contains a body part with 
> > a content-transfer-encoding of binary that is contained in the signed 
> > portion of a multipart/signed, the server MUST NOT alter the 
> > content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
> > "[CANT-CONVERT]" special information token.
> 
> This I have a problem with. I don't believe the server should be enforcing
> these kind of policy decisions on the clients behalf. Garbage in, garbage
> out. And this doesn't solve the problem of a multipart/signed binary CTE
> message being injected via LMTP with CHUNKING.

I agree.   The server certainly must accept a signed message with a CTE of
binary.   There are huge good reasons why this is a valid thing to want to
do, and may in fact be the driving force behind the binary requirement.
 
> The correct solution (which is outside the scope of this draft) is
> to label sections with the original CTE whenever a transformation is
> applied. I think I'll write up a draft to discuss this.

I don't know about that either.

The problem comes when a non BINARY capable client fetches the message or 
parts.   Then the server is faced with an issue.   As Lyndon notes, how 
the message got there is secondary, it now has to do something intelligent
with it.

And really, the exact case is when the client tries to fetch the MIME 
body structure that includes the signature blocks.   At that point it MUST 
convert, but it SHOULD issue some type of warning to the client letting it
know that content conversion was performed that will affect any signature 
security processing on the message.   Of course, fetching the entire 
rfc822 in this case would trigger this -- sigh ... Outlook.

In practice, this is not likely to be a big deal.   Anybody who uses 
BINARY is going to be do so in the presence of a complete BINARY solution 
that includes UA, MTA, and IMAP server.   They all pretty much will have 
to work together to get true BINARY stuff going in the general case.   
Becaue the Internet at large does not have good (if any really) binary 
support, this will likely be constrained to use in local infrastructure 
cases or special use like VPIM.   In either case, everything will be up to
snuff and it should work.   As things improve in the Internet in general, 
then those boundaries, enforced purely by new software deployment -- not 
standards, will expand.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 27 Jul 2001 12:42:44 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY version 3
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, July 27, 2001 11:45 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:
>> (3) In section 5.4, I'd add: If an APPEND command contains a body part
>> with  a content-transfer-encoding of binary that is contained in the
>> signed  portion of a multipart/signed, the server MUST NOT alter the
>> content-transfer-encoding and MAY (MUST?) reject the APPEND command with
>> a  "[CANT-CONVERT]" special information token.
>
> This I have a problem with. I don't believe the server should be enforcing
> these kind of policy decisions on the clients behalf. Garbage in, garbage
> out. And this doesn't solve the problem of a multipart/signed binary CTE
> message being injected via LMTP with CHUNKING.
>
> The correct solution (which is outside the scope of this draft) is
> to label sections with the original CTE whenever a transformation is
> applied. I think I'll write up a draft to discuss this.

I guess I can live with that, but please consider putting in some "servers 
MAY reject" language.  There are two camps in the IETF: "servers should 
enforce standards aggressively on interactive connections to deter 
standards creep" and "garbage in, garbage out".  There are server 
implementors in the former camp who will reject APPENDed messages which 
violate standards egregiously, so one may as well give the client 
implementors fair warning.

		- Chris

Date: Fri, 27 Jul 2001 11:41:05 -0700
From: Jutta Degener <[email-masked]>
Organization: Mediagate
To: IMAP Extensions WG <[email-masked]>
Subject: Re: MULTIAPPEND may be a mistake
Sender: [email-masked]

Nobody doubts that transactions would be nice to have, powerful
transactions even nicer.  But they're not required for MULTIAPPEND,
and they're tricky to implement in systems that don't already have them.

MULTIAPPEND, since it's one command, can be handled in small systems
by locking a mailbox, appending, and unlocking the mailbox.  As soon
as you stretch the transaction period across multiple commands, you're
opening a can of synchronization problems that IMAP has so far wisely
stayed away from.

Jutta <[email-masked]>

Date: Fri, 27 Jul 2001 10:43:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: imapv, multiappend, sort, and thread drafts
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Nobody bothered to tell me, and thus these drafts all expired this month.

I created versions with updated dates, which are on
	ftp://ftp.cac.washington.edu/mail/
but the internet-drafts bureaucracy won't accept them until August 14.

I would prefer not to hear any snide comments.

Organization: ACI Worldwide - Advanced Technology Group
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY version 3 
Date: Fri, 27 Jul 2001 11:45:53 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> (1) The MIME 8-bit content-transfer-encoding forbids NUL, so your example 
> in section 4 of 8-bit with NUL is not a valid example.

Oops.

> (2) The spec needs to explicitly mention the following scenario:
>   (A) BINARY aware client appends a message with CTE binary body part.
>   (B) Non-BINARY aware IMAP4 compliant client fetches that message.

> The only feasible way to deal with that scenario is for the server to act 
> as if the BINARY body part was actually base64 encoded to the client in 
> step B.  This impacts both the BODYSTRUCTURE and the actual BODY fetch.  An 
> important interoperability scenario.

Okay, I'll add text to call this out explicitly.

> (3) In section 5.4, I'd add: If an APPEND command contains a body part with 
> a content-transfer-encoding of binary that is contained in the signed 
> portion of a multipart/signed, the server MUST NOT alter the 
> content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
> "[CANT-CONVERT]" special information token.

This I have a problem with. I don't believe the server should be enforcing
these kind of policy decisions on the clients behalf. Garbage in, garbage
out. And this doesn't solve the problem of a multipart/signed binary CTE
message being injected via LMTP with CHUNKING.

The correct solution (which is outside the scope of this draft) is
to label sections with the original CTE whenever a transformation is
applied. I think I'll write up a draft to discuss this.

--lyndon

From: Edward Hibbert <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: RE: MULTIAPPEND may be a mistake
Date: Thu, 26 Jul 2001 09:24:10 +0100
Sender: [email-masked]

I haven't been following the MULTIAPPEND discussion closely, so I can't
comment on whether transactions would help there, but in general I am
strongly in favour of introducing them.  

I think it would help in a number of areas:
- We've had discussions about an atomic MOVE command.  Transactions open up
the possibility of achieving this without introducing a separate command.
- I would be in favour of going further and covering multiple mailboxes; I
know of clients which attempt to set up (and delete) multiple related
messages in multiple mailboxes, and get confused if things go wrong partway
through.  Of course those clients could be better written to cope with those
cases, but I think the problem is that the lack of a transactional mechanism
forces over-complicated processing into the clients.  I'd rather force it
into the server instead :-).
- I think it might help with the problem that the conditional store
extension is attempting to solve too, though I've not been following that
closely enough to be sure.

It's always dangerous to argue from a particular implementation, but we
already have a (cross-mailbox) transaction mechanism which fits naturally
with this.

However we'd need to talk carefully about locking; presumably a TRANSACTION
START locks a mailbox exclusively against other modifications?

Regards,

Edward Hibbert
Internet Applications Group
Data Connection Ltd
Tel:	+44 131 662 1212		Fax:	+44 131 662 1345
Email:	[email-masked]	Web:	http://www.dataconnection.com

-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 12:10 AM
To: IMAP Extensions WG
Subject: MULTIAPPEND may be a mistake

I have been thinking a lot about MULTIAPPEND and I believe it is a mistake.

My counter proposal is to add three commands to IMAP:

	TRANSACTION START
	TRANSACTION END
	TRANSACTION CANCEL

These modify the behavior of STORE and APPEND such that the "OK" response 
to those commands mean the result is successful so far, but has not 
necessarily been committed.  Certain commands (EXPUNGE, SELECT, EXAMINE, 
UNSELECT) would not be permitted during a transaction (they would either 
fail with a BAD or cancel the transaction, not sure which the spec should 
say).  All commands within a TRANSACTION must apply to the same mailbox. 
All write operations within a TRANSACTION are completed in order.

This is only marginally more difficult to implement on the server side than 
MULTIAPPEND since it adds flags to the mix, but is much more powerful.  In 
addition to providing all the functionality of MULTIAPPEND, this massively 
simplifies the error recovery for a disconnected client replaying its cache.

Furthermore, there are three desirable properties when doing bulk APPENDs:

	* atomicity
	* keep the pipe full (no stalling for a round trip)
	* server can report an error in the middle

The combination of MULTIAPPEND and LITERAL+ can only accomplish two of 
these three properties at a time.  The combination of TRANSACTION and 
LITERAL+ can accomplish all three at the same time.

I also think TRANSACTION may be simpler to retrofit into clients which 
already do bulk APPENDs.

		- Chris

Date: Wed, 25 Jul 2001 23:11:07 -0400
From: Tony Hansen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

And even on Unix, it depends on the filesystem implementation. All you
might need is a stat(2).

	Tony

Chris Newman wrote:
> 
> --On Wednesday, July 25, 2001 8:42 -0700 Mark Crispin
> <[email-masked]> wrote:
> > It needs to be emphasized that is NOT a cheap operation if the hierarchy
> > is based upon a filesystem. In the case of %, the directory has to be opened and
> > examined. ...
> 
> It depends on which filesystem.  For example, on a MacOS filesystem it adds
> no overhead.
> 
>                 - Chris

Date: Wed, 25 Jul 2001 16:10:29 -0700
From: Chris Newman <[email-masked]>
Subject: MULTIAPPEND may be a mistake
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have been thinking a lot about MULTIAPPEND and I believe it is a mistake.

My counter proposal is to add three commands to IMAP:

	TRANSACTION START
	TRANSACTION END
	TRANSACTION CANCEL

These modify the behavior of STORE and APPEND such that the "OK" response 
to those commands mean the result is successful so far, but has not 
necessarily been committed.  Certain commands (EXPUNGE, SELECT, EXAMINE, 
UNSELECT) would not be permitted during a transaction (they would either 
fail with a BAD or cancel the transaction, not sure which the spec should 
say).  All commands within a TRANSACTION must apply to the same mailbox. 
All write operations within a TRANSACTION are completed in order.

This is only marginally more difficult to implement on the server side than 
MULTIAPPEND since it adds flags to the mix, but is much more powerful.  In 
addition to providing all the functionality of MULTIAPPEND, this massively 
simplifies the error recovery for a disconnected client replaying its cache.

Furthermore, there are three desirable properties when doing bulk APPENDs:

	* atomicity
	* keep the pipe full (no stalling for a round trip)
	* server can report an error in the middle

The combination of MULTIAPPEND and LITERAL+ can only accomplish two of 
these three properties at a time.  The combination of TRANSACTION and 
LITERAL+ can accomplish all three at the same time.

I also think TRANSACTION may be simpler to retrofit into clients which 
already do bulk APPENDs.

		- Chris

Date: Wed, 25 Jul 2001 15:22:23 -0700
From: Chris Newman <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
To: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

--On Wednesday, July 25, 2001 8:42 -0700 Mark Crispin 
<[email-masked]> wrote:
> It needs to be emphasized that is NOT a cheap operation if the hierarchy
> is based upon a filesystem.

It depends on which filesystem.  For example, on a MacOS filesystem it adds 
no overhead.

		- Chris

Date: Wed, 25 Jul 2001 08:42:36 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

On Wed, 25 Jul 2001 09:15:43 -0400, Barry Leiba wrote:
> > I'll probably have LIST/LSUB always return the CHILDREN flags (they
> > are very inexpensive).
> The reason for having the client ask for it is not to save bytes (though I
> suppose it's reasonable to do that), but to give the sever the option of
> avoiding the overhead if the client doesn't want the information.  If it's
> pretty much free for your server to do it, you may certainly return the
> flags even when they're not requested.

It needs to be emphasized that is NOT a cheap operation if the hierarchy is
based upon a filesystem.  In the case of %, the directory has to be opened and
examined.  Since that's what some clients do now anyway, I'm not opposed to
indicating children, but want the option of not doing so unless the client
asks for it.

Of course, in the case of *, children flags are completely unnecessary since
it will be obvious from the output whether or not there are children!  [Think
about this.]

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Date: Wed, 25 Jul 2001 09:15:43 -0400
Sender: [email-masked]

> there are any clients which currently look for \Has[No]Children.  If so,
> then I'll probably have LIST/LSUB always return the CHILDREN flags (they
> are very inexpensive).  Otherwise, I'll leave it selectable via LISTEXT,
> to reduce the number of bytes sent to the client.

The reason for having the client ask for it is not to save bytes (though I
suppose it's reasonable to do that), but to give the sever the option of
avoiding the overhead if the client doesn't want the information.  If it's
pretty much free for your server to do it, you may certainly return the 
flags even when they're not requested.  The number of extra bytes is minimal,
except in very long lists.

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 24 Jul 2001 22:05:27 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

Barry Leiba wrote:
> 

[...]

> > 4. Are there any existing clients which implement standalone CHILDREN
> > (draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
> > advertising it in addition to LISTEXT, or should any new CHILDREN
> > implementations do so only under the LISTEXT umbrella?
> 
> As CHILDREN evolved, it was actually decided NOT to advertise a capability
> string for it, because as the draft was written there was no way to ask
> for the info or not.  So a client could determine that it was supported by
> the presence of the flags.

OK, that simplifies things a little.  I'm still curious about whether
there are any clients which currently look for \Has[No]Children.  If so,
then I'll probably have LIST/LSUB always return the CHILDREN flags (they
are very inexpensive).  Otherwise, I'll leave it selectable via LISTEXT,
to reduce the number of bytes sent to the client.

Thoughts?

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 15:22:38 -0400
Sender: [email-masked]

> 1. The discussion of \PlaceHolder incorrectly refers to \NoSelect
> instead of \Noselect.

Atoms are case-insensitive.

> 2. The second example uses the option SUBSCRIBE instead of SUBSCRIBED.

Already fixed in my draft, along with the erroneous reference to
"SUBSCRIPTIONS" later.

> 1. Is \NonExistent ONLY intended to be used for subscribed mailboxes, or
> can/should it be used for other mailboxes in the hierarchy.  For
> example, we have a subscribed mailbox foo/bar, but mailbox foo doesn't
> exist.  Should LIST (SUBSCRIBED) "" % return
> 
> * LIST (\NonExistent \PlaceHolder) "/" "foo"
> 
> or should \Noselect be used in place of \Nonexistent?  Or, is just
> \PlaceHolder sufficient?

I'd say that \NonExistent should be used in any case where it's possible
to have an entity returned that doesn't exist.  So if "a/b/c/d/e" is 
subscribed to, and nothing in the whole hierarchy exists, then whenever
there's cause to return "a" or "a/b" or "a/b/c" or "a/b/c/d", they should
also be marked \NonExistent.  Theoretically, this would apply in cases
other than with the SUBSCRIBED option, but there aren't any other cases
where this could happen (since we don't allow truly missing hierarchy
levels; we can only mark those \Noselect).

Since the SUBSCRIBED option demands that all flags be accurate, you'd
need to return both flags... because both are true.

> 2. What should the flags be for a LIST response which returns just a
> namespace prefix?  For instance, given the namespace
> 
> * NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))
> 
> and assuming that we have mailbox "Shared Folders/foo" which is
> subscribed and exists, should LIST (SUBSCRIBED) " % return
> 
> * LIST (\Noselect \PlaceHolder) "/" "Shared Folders"
> 
> or should it return only one or the other?  Should \NonExistent be used
> in place of \Noselect?

I think a namespace is an existent entity, so it gets marked \Noselect.

> 3. When doing a LIST (SUBSCRIBED CHILDREN), does the presence of
> \PlaceHolder imply \HasChildren, or should both flags be returned (ala
> \Noinferiors implies and supercedes \HasNoChildren)?

Clearly \PlaceHolder implies \HasChildren, but I see no reason not to send
them both.  If anyone feels strongly about it, I'm happy to say that because
\PlaceHolder implies \HasChildren, the latter SHOULD NOT be returned.  But
I won't make that change unless some people really think I should.

> 4. Are there any existing clients which implement standalone CHILDREN
> (draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
> advertising it in addition to LISTEXT, or should any new CHILDREN
> implementations do so only under the LISTEXT umbrella?

As CHILDREN evolved, it was actually decided NOT to advertise a capability
string for it, because as the draft was written there was no way to ask 
for the info or not.  So a client could determine that it was supported by
the presence of the flags.

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shapira-snap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shapira-snap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shapira-snap-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 24 Jul 2001 01:08:30 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: New revision of CONDSTORE draft (conditional store)
Sender: [email-masked]

In July I've submitted two revisions of conditional store extension
(CONDSTORE).
Current draft is named draft-melnikov-imap-condstore-02.txt.

Here is the list of changes:
Changes from -01 to -02:
     1.  Added MODTIME data item to STATUS command.
     2.  Added OK untagged response to SELECT/EXAMINE.
     3.  Clarified that MODIFIED response code contains list of UIDs for
          conditional UID STORE and message set for STORE.
     4.  Added per-message modtime.
     5.  Added PERFLAGMODTIME capability.
     6.  Fixed several bugs in examples.
     7.  Added more comments to ABNF.

    Changes from -00 to -01:
     1.  Refreshed the list of Open Issues.
     2.  Changed "attr-name" to "entry-name", because modtime applies to
entry,
           not attribute.
     3.  Added MODTIME untagged response.
     4.  Cleaned up ABNF.
     5.  Added "Acknowledgments" section.
     6.  Fixed some spelling mistakes.

List of open issues:

    1). How specify different UNCHANGESINCE for different flags in the
          same STORE?  Do we want such granularity anyway?

    2). The document assumes that each flag has a corresponding
          ANNOTATE entry. This has to be synchronized with ANNOTATE draft.

    3). "If the "modtime" of any metadata item specified in STORE
         operation for any message in the message set is greater
         than the unchangedsince value, then the store fails with a
         MODIFIED response code that includes message set of all
         messages that failed UNCHANGESINCE test."

        This basically means that server must continue conditional store
          operation to find all messages for which test fails. Is it
          reasonable, or should the text be changed from "all messages" to
          "at least one message".

    4). MODTIME Untagged Response specifies a message set modtime applies
to.
          Can anybody think of a reason why it is a bad idea? Message set
          is not really required, because MODTIME untagged response must
          follow corresponding untagged FETCH responses.
        Should we use UID set instead?

    5). Should SEARCH MODTIME require MODTIME untagged response?

          SEARCH doesn't cause updates, unless they are the result of some
          other operation. However SEARCH MODTIME forces server to read
          modtime, so server can report this information anyway.

    6). Add support for SORT extension?

I've also implemented revision 2 of the draft in our server, so I can share
my experience.

Comments?
__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Mon, 23 Jul 2001 16:37:10 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY version 3
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

The binary draft (-04) is looking great, but it needs a bit more 
wordsmithing:

(1) The MIME 8-bit content-transfer-encoding forbids NUL, so your example 
in section 4 of 8-bit with NUL is not a valid example.

(2) The spec needs to explicitly mention the following scenario:
  (A) BINARY aware client appends a message with CTE binary body part.
  (B) Non-BINARY aware IMAP4 compliant client fetches that message.

The only feasible way to deal with that scenario is for the server to act 
as if the BINARY body part was actually base64 encoded to the client in 
step B.  This impacts both the BODYSTRUCTURE and the actual BODY fetch.  An 
important interoperability scenario.

(3) In section 5.4, I'd add: If an APPEND command contains a body part with 
a content-transfer-encoding of binary that is contained in the signed 
portion of a multipart/signed, the server MUST NOT alter the 
content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
"[CANT-CONVERT]" special information token.

		- Chris

--On Friday, May 18, 2001 15:24 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> I've submitted the -03 revision to the I-D editor. You can take an
> early peek via:
>
>  http://research.messagingdirect.com/draft-nerenberg-imap-binary-03.txt
>
> The major change is the replacement of the horrid BINARYSTRUCTURE goop
> with the new BINARY.SIZE attribute.
>
> --lyndon

Date: Mon, 23 Jul 2001 16:31:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

Just for kicks, I started hacking a LISTEXT/LIST-SUBSCRIBED
implementation for Cyrus and came across a couple of nits and a couple
of questions.

Nits:

1. The discussion of \PlaceHolder incorrectly refers to \NoSelect
instead of \Noselect.

2. The second example uses the option SUBSCRIBE instead of SUBSCRIBED.

Questions:

1. Is \NonExistent ONLY intended to be used for subscribed mailboxes, or
can/should it be used for other mailboxes in the hierarchy.  For
example, we have a subscribed mailbox foo/bar, but mailbox foo doesn't
exist.  Should LIST (SUBSCRIBED) "" % return

* LIST (\NonExistent \PlaceHolder) "/" "foo"

or should \Noselect be used in place of \Nonexistent?  Or, is just
\PlaceHolder sufficient?

2. What should the flags be for a LIST response which returns just a
namespace prefix?  For instance, given the namespace

* NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))

and assuming that we have mailbox "Shared Folders/foo" which is
subscribed and exists, should LIST (SUBSCRIBED) " % return

* LIST (\Noselect \PlaceHolder) "/" "Shared Folders"

or should it return only one or the other?  Should \NonExistent be used
in place of \Noselect?

3. When doing a LIST (SUBSCRIBED CHILDREN), does the presence of
\PlaceHolder imply \HasChildren, or should both flags be returned (ala
\Noinferiors implies and supercedes \HasNoChildren)?

4. Are there any existing clients which implement standalone CHILDREN
(draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
advertising it in addition to LISTEXT, or should any new CHILDREN
implementations do so only under the LISTEXT umbrella?

Thanks,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: [email-masked]
cc: [email-masked]
Subject: draft-segmuller-imap-structure-00
Organization: ACI Worldwide - Advanced Technology Group
Date: Fri, 20 Jul 2001 14:56:26 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

Wolfgang, would it not make more sense to return _all_ the MIME
header information? If we need to query for something besides a
content-* header, we have to fall back to the old way of doing it,
or define a new extension to retrieve the new headers. The current
scope is much to narrow I think.  Generalizing it to return all
the MIME headers would make it much more useful.

If you do extend it to return all the MIME header information then
I would also suggest changing the fetch attribute name to MIMESTRUCTURE,
to better describe what is being requested.

--lyndon

Date: Fri, 20 Jul 2001 16:29:40 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

FYI, there appears to be a typo in the options syntax which uses the
token "SUBSCRIPTIONS".

BTW, have any client vendors implemented this yet?  I've been looking
this over and I can add it to Cyrus with a couple of hours work, but I
don't want to take the time if there are no clients to test with and/or
the draft isn't stable yet.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: Steve Hole <[email-masked]>
Date: Fri, 20 Jul 2001 12:14:56 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

On Fri, 20 Jul 2001 11:21:18 -0400 Barry Leiba <[email-masked]> 
wrote:

> 
> > Presumably, the SUBSCRIPTIONS option requires that the server return full
> > information about folders that are subscribed, unlike LSUB which just
> > returns a list of subscribed folders.
> 
> Hm.  If you only say "presumably", then I haven't made it clear enough; I 
> thought I had.  Should I put more words in, clearer words, or what?  Do you 
> have any specific phrasing for a certain spot that you think will raise it 
> from "Presumably," to "I clearly see that"?

Actually, (1) I only scanned it, and (2) I wanted to point out this bit 
specifically to the list.

So, I don't believe there is any clarification action required.
 
Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 20 Jul 2001 11:21:18 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

> Presumably, the SUBSCRIPTIONS option requires that the server return full
> information about folders that are subscribed, unlike LSUB which just
> returns a list of subscribed folders.

Hm.  If you only say "presumably", then I haven't made it clear enough; I 
thought I had.  Should I put more words in, clearer words, or what?  Do you 
have any specific phrasing for a certain spot that you think will raise it 
from "Presumably," to "I clearly see that"?

> My God, I hope that nobody actually reads that sentence above that doesn't
> have a long history with IMAP, because it will just be the dumbest
> sounding thing in the history of mankind.

:-)

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Fri, 20 Jul 2001 09:16:32 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

Presumably, the SUBSCRIPTIONS option requires that the server return full 
information about folders that are subscribed, unlike LSUB which just 
returns a list of subscribed folders.

My God, I hope that nobody actually reads that sentence above that doesn't
have a long history with IMAP, because it will just be the dumbest 
sounding thing in the history of mankind.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 19 Jul 2001 13:38:59 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

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

Hi all.  Sorry for the horrid delay in this; I've just submitted the 
attached update to the I-D editor.  I believe it covers the LIST extensions 
issues we discussed way back when, and sorts out the items that were in 
contention.  I think we should submit enhanced selection criteria as a 
separate extension, based on these basic LIST extensions, and I'll be happy 
to do that if we want to talk about them at the upcoming IETF meeting (ah, 
assuming I get approval for the travel).  We can start discussing them here.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

--==========618440821==========
Content-Type: text/plain; charset=us-ascii;
 name="draft-ietf-imapext-list-extensions-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-01.txt"; size=18441

IMAP Extensions Working Group                                   B. Leiba
Internet Draft                           IBM T.J. Watson Research Center
Document: draft-ietf-imapext-list-extensions-01.txt            July 2001
                                                    Expires January 2002

                     IMAP4 LIST Command Extensions

Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.

   A revised version of this draft document will be submitted to the RFC
   editor as an Proposed Standard for the Internet Community. 
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].  This document will expire before 31
   January 2002.  Distribution of this memo is unlimited.

1. Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   add extensions that require specialized lists (see [MboxRefer] for an
   example) we expand the number of list commands, as each extension
   must add its function to both LIST and LSUB.  This document describes
   extensions to the LIST command that allow these additions to be done
   in mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

B. Leiba                  Expires January 2002                  [Page
1]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

2. Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].

3. Introduction

   The extensions to the LIST command will be accomplished by amending
   the syntax to allow options to be specified.  The list of options
   will replace the several commands that are currently used to mix and
   match the information requested.  The new syntax is backward-
   compatible, with no ambiguity: if the first word after the command
   name begins with a parenthesis, the new syntax is being used; if it
   does not, it's in the original syntax.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB commands
   described in [MboxRefer].  We are also defining the mechanism to
   request extended mailbox information, such as is described in the
   now-expired "Child Mailbox Extension" draft [ChildMbox].  The base
   LSUB command is not deprecated by this extension; rather, this
   extension adds a way to obtain subscription information with more
   options, with those server implementations that support it.  Clients
   that simply need a list of subscribed mailboxes, as provided by the
   LSUB command, SHOULD continue to use that command.

4. LIST Command Options

   The LIST command syntax is extended by adding a parenthesized list of
   command options between the command name and the reference name (see
   the formal syntax in section 6 for specific details).  Command
   options will be defined in this document and in approved extension
   documents; each option will be enabled by a capability string (one
   capability may enable multiple options), and a client MUST NOT send
   an option for which the server has not advertised support.  A server
   MAY ignore options it does not recognize.

   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  This document also defines the "LIST-
   SUBSCRIBED" capability string; see the "SUBSCRIBED" option below.

B. Leiba                  Expires January 2002                  [Page 2]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   The options defined in this specification are

       SUBSCRIBED - causes the LIST command to list subscribed
          mailboxes, rather than the actual mailboxes.  This will often
          be a subset of the actual mailboxes.  It's also possible for
          this list to contain the names of mailboxes that don't exist. 
          In any case, the list MUST include exactly those mailbox names
          that match the selection criteria and are subscribed to.  This
          option is intended to supplement the LSUB command, and support
          for it is optional -- a server that supports the SUBSCRIBED
          option indicates so through the LIST-SUBSCRIBED capability.

          Of particular note are the mailbox flags as returned by this
          option, compared with what is returned by LSUB.  With the
          latter, the flags returned may not reflect the actual flag
          status on the mailbox, and the \NoSelect flag has a special
          meaning (it indicates that this mailbox is not, itself,
          subscribed, but that it has child mailboxes that are).  With
          the SUBSCRIBED option described here, the flags are accurate
          and complete, and have no special meanings.

          "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
          and some servers must do significant extra work to respond to
          "LIST (SUBSCRIBED)".  Because of this, clients SHOULD continue
          to use "LSUB" unless they specifically want the additional
          information offered by "LIST (SUBSCRIBED)".  At the same time,
          servers SHOULD support the LIST-SUBSCRIBED capability even if
          it entails extra work, because a client that wants the
          information will still obtain it by using LSUB followed by a
          series of LIST commands, so servers might as well make it
          easier.

          This option defines a new mailbox flag, "\NonExistent", that
          indicates that a mailbox is subscribed to, but does not
          actually exist.  The "\NonExistent" flag MUST be supported and
          MUST be accurately computed.

       REMOTE - causes the LIST command to show remote mailboxes as
          well as local ones, as described in [MboxRefer].  This option
          is intended to replace the RLIST command and, in conjunction
          with the SUBSCRIBED option, the RLSUB command.  This option is
          only available on servers that also support RFC-2193.

       CHILDREN - Requests mailbox child information as originally
          proposed in [ChildMbox].  See section 5, below, for details. 
          Support for this is optional, but this option MUST be accepted
          by all servers (though it MAY be ignored).

   The LISTEXT capability also defines a new mailbox flag,

B. Leiba                  Expires January 2002                  [Page 3]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   "\PlaceHolder", that indicates that the designated mailbox does not
   meet the selection criteria of the given LIST command, but that it
   has one or more child mailboxes that do [EDITORIAL NOTE: "might"?]. 
   The LSUB command indicates this condition by using the "\NoSelect"
   flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   "\PlaceHolder" flag is more general, in that it can be used with any
   extended set of selection criteria.

5. The CHILDREN Option

   The CHILDREN option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [ChildMbox].  The CHILDREN
   option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified, or MAY ignore the option entirely.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.   When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.

   The Child Mailbox Extension provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST '' * or a LIST '' % for each mailbox name.

   The Child Mailbox Extension defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren. 
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN option is provided to indicate that the client
   particularly wants this information.  If the CHILDREN option is
   present, the server SHOULD return these attributes even if their
   computation is expensive.

\HasChildren - The presence of this attribute indicates that the mailbox
       has child mailboxes.

       A server SHOULD NOT set this attribute if there are child
       mailboxes, and the user does not have permissions to access any
       of them. In this case, \HasNoChildren SHOULD be used.

B. Leiba                  Expires January 2002                  [Page 4]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

       In many cases, however, a server may not be able to efficiently
       compute whether a user has access to all child mailboxes.  As
       such a client MUST be prepared to accept the \HasChildren
       attribute as a hint.  That is, a mailbox MAY be flagged with the
       \HasChildren attribute, but no child mailboxes will appear in
       the LIST response.

\HasNoChildren - The presence of this attribute indicates that the
       mailbox has NO child mailboxes that are accessible to the
       currently authenticated user.

   In some instances a server that supports the Child Mailbox Extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.

   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute.  In particular, some
   servers may not be able to combine the SUBSCRIBED and CHILDREN
   options.  Such servers MUST honour the SUBSCRIBED option, and they
   will simply ignore the CHILDREN option if both are requested.

   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in a LIST response.

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

6. Examples

   The first example shows the complete local hierarchy that will be
   used for the other examples.

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

B. Leiba                  Expires January 2002                  [Page 5]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   In the next example, we'll see the subscribed mailboxes.  This is
   similar, but not equivalent, to <LSUB "" "*">.  Note that the mailbox
   called "Fruit/Peach" is subscribed to, but does not actually exist
   (perhaps it was deleted while still subscribed).  And the "Fruit"
   mailbox is not subscribed to, but it has two subscribed children.

       C: A02 LIST (SUBSCRIBE) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\PlaceHolder) "/" "Fruit"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST (\NonExistent) "/" "Fruit/Peach"
       S: A02 OK done

   The next example shows the use of the CHILDREN option.  The client,
   without having to list the second level of hierarchy, now knows which
   of the top-level mailboxes have sub-mailboxes (children) and which do
   not.  Note that it's not necessary for the server to return the
   \HasNoChildren flag for the inbox, because the \NoInferiors flag
   already implies that, and has a stronger meaning.

       C: A03 LIST (CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: A03 OK done

   In this example we see more mailboxes, which reside on another server
   to which we may obtain referrals.  This is similar to the command
   <RLIST "" "%">.  We also see the mixing of two options.  Note that in
   the case of the remote mailboxes, the server might or might not be
   able to include CHILDREN information; it includes it if it can, and
   omits it if it can't.

       C: A04 LIST (REMOTE CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: * LIST () "/" "Bread"
       S: * LIST (\HasChildren) "/" "Meat"
       S: A04 OK done

7. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

B. Leiba                  Expires January 2002                  [Page 6]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   child-mbox-flag = "\HasChildren" / "\HasNoChildren"
                      ; flags for Child Mailbox Extension, at most one
                      ; possible per LIST response

   list            = "LIST" [SP list-options] SP mailbox SP list-mailbox

   list-options     = "(" [option *(SP option)] ")"

   mbox-list-oflag := child-mbox-flag / "\NonExistent" / "\PlaceHolder"

   option           = "SUBSCRIPTIONS" / "CHILDREN" / "REMOTE" /
                     option-extension

   option-extension = atom

8. Security Considerations

   This document describes syntactic changes to the specification of the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  They
   are described in [IMAP4] and [MboxRefer].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.   In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

9. References

   [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.

   [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193;
   Microsoft Corporation; September 1997.

B. Leiba                  Expires January 2002                  [Page
7]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension";
   draft-gahrns-imap-child-mailbox-03.txt; Microsoft Corporation;
   November 1997 -- expired, listed for historical reference.

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

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

10. Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in section 5, is theirs.

11. Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

   Phone: 1-914-784-7941
   Email: [email-masked]

B. Leiba                  Expires January 2002     
            [Page 8]
--==========618440821==========--

Date: Thu, 19 Jul 2001 17:58:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Steve Hole <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

By definition, the notications may be divided into the set of interesting
ones and the set of uninteresting ones. One of the sets may be empty in
any given case, but conceptually they exist.

A flood happens if the set of uninteresting notifications is "big" and the
server is sending them to the client.

My intuition says that the set of interesting notifications is closely
related to the set of interesting unsolicited flag updates, to the set of
unsolicited EXPUNGE responses, and so on. Whatever a client is interested
in: If it doesn't want EXPUNGEs for message 1234, it probably won't want
ANNOTATIONs for it either, and vice versa.

If that's right, then ANNOTATION should follow the WINDOW (or similar
mechanism) just like e.g. EXPUNGE does, and that's all there is to it.
Nothing ANNOTATE-specific.

--Arnt

From: Steve Hole <[email-masked]>
Date: Thu, 19 Jul 2001 08:56:22 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 18 Jul 2001 19:16:55 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> One more point to note on this particular issue. One benefit to having 
> flags in ANNOTATE is that it allows splitting the flags into per-user 
> (private) and shared components, so it would be possible to have a per-user 
> answered flag, for example. Of course this also confuses the situation 
> because we would have to specify what happens with conventional IMAP flags 
> wrt storing private or shared.

Make them private by default like any other metadata.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Thu, 19 Jul 2001 08:49:34 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1.1 Build (10) 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"

On Wed, 18 Jul 2001 19:11:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> Another approach is to say that an unsolicited change to an annotation can 
> only be sent if that annotation itself has been previously requested in a 
> FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited 
> changes to /a/b/c, but not to /a/b/d. Thus a client can effectively 
> 'subscribe' to specific annotation changes by doing a fetch for those 
> annotations only.

That means holding an awful lot of state in server though.   I'm not sure 
that as a server author I would like the business logic of this.   
Thinking about it, I don't believe that you will get a flood of changes.  
The general case will be that you are the only one ever modifying the 
state, so and you want the notifications anyway.   If it is much rarer 
shared mailbox situation, you will be getting notifications, but they are 
by definition going to be notifications on shared annotations which seems 
fine as well.   Things like helpdesk mailboxes would seem to require this.

I would keep it simple.   Ask for any annotation, start getting responses.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 19 Jul 2001 01:19:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Steve Hole <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Cyrus Daboo wrote:

> There is also a question of what level of granularity we want for turning
> on the unsolicited notifications. Right now its set so that ANY annotation
> fetch will cause changes to ALL annotations to be sent unsolicited.
>
> Another approach is to say that an unsolicited change to an annotation can
> only be sent if that annotation itself has been previously requested in a
> FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited
> changes to /a/b/c, but not to /a/b/d. Thus a client can effectively
> 'subscribe' to specific annotation changes by doing a fetch for those
> annotations only.

This can [potentially] consume a lot of memory on server side. (Probably not as
match as WINDOW, but nevertheless)

Also, in this case it is probably better to have additional command to request
interest in some annotation tree. With you approach, there is no way to cancel
notifications for an annotation if the annotation is fetched once.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 19 Jul 2001 01:12:13 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Cyrus Daboo wrote:

> Open Issue #3
>
> Currently requires that ANNOTATION unsolicited responses not be sent until
> the client has issued at least one FETCH with an ANNOTATION fetch item. Is
> this prohibition really neccessary?
>
> My personal opinion:
>
> We should avoid sending annotation data unless the client has indicated in
> some way that it will actually use it. The approach of waiting for an
> ANNOTATION fetch seems reasonable. Another option would be to have a switch
> on the SELECT command to tell the server to return unsolicited ANNOTATION
> responses.

I like the idea of implicit enabling of ANNOTATION responses.

I also like the idea of not sending annotation data itself, just send a
notification that some annotation changed (Proposed by Jutta originally if I am
not mistaken).

Adding restriction on annotation size (and maybe untagged reply on select that
reports the limit) seams like a good idea too.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 19 Jul 2001 01:05:10 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mike Gahrns <[email-masked]>
CC: Steve Hole <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

Mike Gahrns wrote:

> Steve Hole writes:
> > I think that, if we have a default, that default should be to store as a
> > private annotation.
> *** Yes, I strongly concur with Steve here.
>
> However, I still question whether there is a need for a default.   Are
> annotations going to be that frequent of operation that the cost of sending
> these few bytes are worth the complexity of defining a default?  I suppose
> if things like normal flag manipulations end up in annotations then this may
> be worth considering, but if annotations are limited to the odd annotation
> on message I doubt whether adding a default is worth it.

I agree with Mike, I would prefer being explicit all the time and have no
default.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

From: "Mike Gahrns" <[email-masked]>
To: "Steve Hole" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: "IMAP Extensions" <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Date: Wed, 18 Jul 2001 17:40:20 -0700
Sender: [email-masked]

Steve Hole writes:
> I think that, if we have a default, that default should be to store as a
> private annotation.
*** Yes, I strongly concur with Steve here.

However, I still question whether there is a need for a default.   Are
annotations going to be that frequent of operation that the cost of sending
these few bytes are worth the complexity of defining a default?  I suppose
if things like normal flag manipulations end up in annotations then this may
be worth considering, but if annotations are limited to the odd annotation
on message I doubt whether adding a default is worth it.

Date: Wed, 18 Jul 2001 19:16:55 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

One more point to note on this particular issue. One benefit to having 
flags in ANNOTATE is that it allows splitting the flags into per-user 
(private) and shared components, so it would be possible to have a per-user 
answered flag, for example. Of course this also confuses the situation 
because we would have to specify what happens with conventional IMAP flags 
wrt storing private or shared.

-- 
Cyrus Daboo

Date: Wed, 18 Jul 2001 19:11:20 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

--On Wednesday, July 18, 2001 04:46:55 PM -0600 Steve Hole 
<[email-masked]> wrote:

>> We should avoid sending annotation data unless the client has indicated
>> in  some way that it will actually use it. The approach of waiting for
>> an  ANNOTATION fetch seems reasonable. Another option would be to have a
>> switch  on the SELECT command to tell the server to return unsolicited
>> ANNOTATION  responses.
>
> I agree.   Note that this is effectively an implicit mode, that is entered
> when ANNOTATION data is requested.   I personally don't have a problem
> with modal behaviour of this type, but others have indicated that they
> don't like it.   I view it as a reasonable optimization.

There is also a question of what level of granularity we want for turning 
on the unsolicited notifications. Right now its set so that ANY annotation 
fetch will cause changes to ALL annotations to be sent unsolicited.

Another approach is to say that an unsolicited change to an annotation can 
only be sent if that annotation itself has been previously requested in a 
FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited 
changes to /a/b/c, but not to /a/b/d. Thus a client can effectively 
'subscribe' to specific annotation changes by doing a fetch for those 
annotations only.

The only reason I propose this is that I'm concerned about a client being 
flooded with annotation changes for annotations it doesn't care about (e.g. 
ones in another vendor's namespace). Given that ANNOTATE doesn't currently 
recommend a maximum size for annotation data (maybe that's something it 
should do) the potential for floods of unsolicted responses on a heavily 
used shared mailbox is fairly large.

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:54:39 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 18 Jul 2001 18:57:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> In that case would we need to define .priv as a suffix at all as it 
> would be redundant? We would only need .shared.

Sounds right.

> So, removing .priv (leaving .shared), and having the default be private 
> seems reasonable to me. We just have to make it clear that if the user 
> isn't allowed to store a private annotation, then storing to default MUST 
> fail (i.e. it MUST NOT add it as a shared annotation). I guess that falls 
> under the security considerations.

Yep.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Wed, 18 Jul 2001 18:57:20 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

--On Wednesday, July 18, 2001 04:44:26 PM -0600 Steve Hole 
<[email-masked]> wrote:

>> How a client learns or changes the default is also an open issue.  One
>> suggestion is to use an additional ACL bit to indicate the current
>> default  state.
>
> Don't worry about it.   Fix the default as private and make pubishing to a
> shared (public) scope always be explicit.

In that case would we need to define .priv as a suffix at all as it would 
be redundant? We would only need .shared.

So, removing .priv (leaving .shared), and having the default be private 
seems reasonable to me. We just have to make it clear that if the user 
isn't allowed to store a private annotation, then storing to default MUST 
fail (i.e. it MUST NOT add it as a shared annotation). I guess that falls 
under the security considerations.

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:50:13 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:51:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> Issue #4
> 
> Should there be a special ACL bit to indicate if annotations are shared or 
> private by default for a mailbox (this is somewhat related to Open Issue 

No.

> #2)? And are the proposed ACL rights for determing 
> read/write/shared/private annotation access acceptable - particularly 
> overlaoding the 's' right for private annotation writes?

Setting access independent rights for the shared and private instances of 
an annotation seems fine.   If one interprets the "s" right as the 
"metadata update right", then certainly annotations qualifies as metadata 
and that seems fine.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:46:55 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:45:29 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> Open Issue #3
> 
> Currently requires that ANNOTATION unsolicited responses not be sent until 
> the client has issued at least one FETCH with an ANNOTATION fetch item. Is 
> this prohibition really neccessary?
> 
> My personal opinion:
> 
> We should avoid sending annotation data unless the client has indicated in 
> some way that it will actually use it. The approach of waiting for an 
> ANNOTATION fetch seems reasonable. Another option would be to have a switch 
> on the SELECT command to tell the server to return unsolicited ANNOTATION 
> responses.

I agree.   Note that this is effectively an implicit mode, that is entered
when ANNOTATION data is requested.   I personally don't have a problem 
with modal behaviour of this type, but others have indicated that they 
don't like it.   I view it as a reasonable optimization.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:44:26 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:41:40 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> Issue #2
> 
> Should annotation stores without a .priv or .shared suffix (i.e. to the 
> 'default') be allowed? This is dangerous because the client won't know for 
> sure whether other users will be able to see the annotation later.

I think that, if we have a default, that default should be to store as a 
private annotation.   My reasoning is simple.   Storing something 
sensitive inadvertently as a shared annotation is potentially disastrous 
ie. loss of job, loss of spouse, death by mafia, imprisonment etc.    
Storing something inadvertently as a private annotation may result in 
badness, but the badness is likely to be things like application failure, 
non-communication etc.    I just believe that the downside results 
inadvertent visibility to the public substantially outweighs the 
alternative.

So

1.  Let them store explicitly to either a .priv or a .shared suffix.

2.  Implicit storage scope is always private.

> How a client learns or changes the default is also an open issue.  One 
> suggestion is to use an additional ACL bit to indicate the current default 
> state.

Don't worry about it.   Fix the default as private and make pubishing to a
shared (public) scope always be explicit.
 
> It may be better to remove the default, and force clients to always 
> explicitly store into one or the other.
> 
> 
> My personal opinion:
> 
> Only allow explicit use of .priv and .shared - no default - because of the 
> added complexity of determining the default and being able to set it. Plus 
> I believe clients would want to make sure that a user explicitly indicates 
> shared or private for an annotation anyway.

I would buy this too.   Either this or with the addition of the fixed 
default of private is fine by me.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Sun, 15 Jul 2001 20:59:19 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #5 Problem with STATUS ABNF in IMAP4rev1
Sender: [email-masked]

[Found this when adding HIGHESTMODTIME status data item to CONDSTORE
extension]

First of all I am not sure whether this is just a cut and paste bug in
ANNOTATE draft, but I found couple references to STATUS, including some
pieces of ABNF. Probably all references to STATUS should be removed from
ANNOTATE, as CONDSTORE already has this functionality.

Anyway,  ANNOTATE and/or CONDSTORE extension have the following problem:

>From IMAPrev1 ABNF:

   mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
                      "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number)
/
                      "STATUS" SP mailbox SP "("
                      [status-att SP number *(SP status-att SP number)]
")" /
                      number SP "EXISTS" / number SP "RECENT"

>From ANNOTATE:

   status            =/ "ANNOTATION-MODTIME"
                       ; modifies original IMAP4 STATUS command

and
   modtime has ACAP syntax.

If you have a close look at ABNF for mailbox-data, you notice that a
value of any status-att can be only a number.  Mark, can you relax this?
I need to be able to use at least "quoted" or "atom" (probably atom).

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 13 Jul 2001 11:22:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

--On Friday, July 13, 2001 12:36 AM -0600 Alexey Melnikov 
<[email-masked]> wrote:

>> Issue #4
>>
>> Should there be a special ACL bit to indicate if annotations are shared
>> or private by default for a mailbox (this is somewhat related to Open
>> Issue
>> # 2)? And are the proposed ACL rights for determing
>> read/write/shared/private annotation access acceptable - particularly
>> overlaoding the 's' right for private annotation writes?
>
> I was objecting to using "s" ACL right before. I don't think we should
> overload its well defined meaning.
> IMHO, we should introduce a new right for that, for example "W" (as
> opposed to "w").

I tend to agree. In which case I think ANNOTATE should explicitly require 
that a server that also does ACL, provide the 'W' bit.

-- 
Cyrus Daboo

Date: Fri, 13 Jul 2001 00:36:06 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

Cyrus Daboo wrote:

> Issue #4
>
> Should there be a special ACL bit to indicate if annotations are shared or
> private by default for a mailbox (this is somewhat related to Open Issue
> #2)? And are the proposed ACL rights for determing
> read/write/shared/private annotation access acceptable - particularly
> overlaoding the 's' right for private annotation writes?

I was objecting to using "s" ACL right before. I don't think we should
overload its well defined meaning.
IMHO, we should introduce a new right for that, for example "W" (as opposed to
"w").

Alexey

From: Steve Hole <[email-masked]>
Date: Wed, 11 Jul 2001 17:24:25 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 15:28:11 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> --On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
> 
> > Message status flags are extensible and have been since the inception of
> > IMAP.
> >
> 
> Thats a good point and does imply another resolution to this issue: that is 
> to remove message flags from annotations for now. We could write up 
> $forwarded and $redirected (the only additional flags currently defined in 
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags, 
> if there was interest. We would still keep the body-part flags in ANNOTATE, 
> of course.

This is really the issue.

If there is a concept of standard-flags-associated-only-with-annotate then
to get the "complete" flag set in a full functionality client, you have to
ask for both.   Not to mention that it is just plain confusing as hell!   
I don't believe it would pass the laugh test from someone who is new to 
IMAP looking at it.

Either

1.  Have all flags exposed in both or

2.  Have flags (binary metadata) exposed only in the store command.

I'm not strongly inclined either way actually, although I do tend toward 
the "both" side.   My reasons:

 * Annotate supports managing arbitrary per-message metadata.

 * Clearly, flags are binary metadata and the store command is a 
   command restricted to arbitrary binary metadata.

 * Annotate clearly could provide a more general mechanism for managing 
   all of the existing binary metadata as well as new metadata.

Of course, the "it could" argument is not a hugely strong argument.   I 
have always preferred general models to specific models though.

The reasons stated that supporting the both model are:

1.   It means maintaining two code paths to the same data in the server.

2.   The client is forced to detect which command set to use to get access
to the data.

3.   ???? (please fill in more that I have missed)

I would say to address the issues that are enumerated above:

1.   Managing arbitrary per-message meta data in server is likely to be 
non-trivial.   It will certainly be more difficult for some that for 
others.   In our case, for example, all of our metadata is held in a 
database that is already out-of-band of the message itself.   As a result,
while not trivial, it is not particularly difficult to do either.   
Supporting the two code paths in response to a fetch would be easy after 
the metadata storage extensions.   Supporting the unsolicited metadata 
notifications wouldn't be that hard because we already have a notification
posting system that is generally focused on metadata rather than just on 
flags.   To issue simultaneous ANNOTATE and FLAGS unsolicited responses is
not that big a deal.

The question is - how do you decide as the server to issue both or just 
ANNOTATE (more efficient) responses.   There would have to be a way to 
indicate "just do ANNOTATE please" to the server, and that is somewhat 
blech.

2.  Multiple code paths in the client, I'm going to claim, is actually 
pretty easy.   Hell, the c-client had simple fallback code for a long time
from IMAP4 to IMAP2bis.    Ours has numerous instances of fallback code 
based on tests for the existence/non-existence of a capability.   Things 
that come to mind immediately are referrals and ACL's.   The behaviour 
changes (for efficiency purposes) based on whether those things exist or 
not.    I could certainly imagine where I would conditionally excercise 
the ANNOTATE extension in preference to the base STORE and FETCH FLAGS.   
I can easily imagine where this would be done in the c-client as well.

As well, the client shouldn't actually care all that much about receiving 
FLAGS and ANNOTATE responses from the server, even though receiving both 
would be inefficient.   If both were issued, you would get redundant cache
updates as you processed both unsolicited responses.

So ...

Based on the objections I've heard so far, I think that you could do the 
both model IF you can find a way to engage "send ANNOTATE instead of 
FLAGS responses".   If not, it is much more messy.

Perhaps simply issuing a fetch for annotations would be enough to engage 
it.   This is an implicit mode, which most people will probably barf on.

Perhaps an explicit, command to engage it.  Once again, modal behaviour 
though.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Wed, 11 Jul 2001 16:11:41 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 12:00 PM -0700, Mark Crispin wrote:

>On Wed, 11 Jul 2001 13:33:14 -0500, Pete Resnick wrote:
>>  Not really. Of course, you have the separate old code for dealing
>>  with old servers, but (like we did in Eudora when UIDL came along for
>>  POP) you stop maintaining the old code when adding new features.
>
>UIDL

Was an example of a protocol extension that caused us to have two 
different code paths. I can name others if you like. The point (which 
you missed) was that having an extension that addresses a particular 
need may allow you to avoid continuing to develop code paths that do 
the same thing in a less general way.

>  > Nonsense. It is a trivial change to the server, it benefits every
>  > client,
>
>Please explain how you are able to determine what is a "trivial change to the
>server" for every server, and what "benefits every client."

Servers:

A server must keep track of flag changed for connected clients now. 
To map "change this annotation" to "change this annotation *and* 
change this flag" and vice-versa is architecturally simple. Yes, it 
is possible that servers are written that make this hard, but I would 
say those would be poorly architected servers.

Clients:

Allowing clients to use a single mechanism for similar functions is 
simplifying. Whether or not all clients immediately benefit from this 
is not what I am talking about; I'm talking about allowing clients to 
take advantage of a simplification being beneficial.

>I have seen no evidence that either claim is true.

I'm not at all sure what kind of evidence you might be referring to.

>  > and it doesn't make an arbitrary distinction between "flags
>>  for message status" and "flags for message status that we decided
>>  were important back when we first wrote the protocol".
>
>I can't believe that anyone who is familiar with the architecture of IMAP
>would make such a statement.
>
>Message status flags are extensible and have been since the inception of IMAP.

Their extensibility is completely dependent on the server 
implementation. Extensibility in ANNOTATE (as I understand it) is 
built-in; as a client I can create any flag I want, whether or not 
the server knows about it. And because ANNOTATE is very clear on the 
requirements of adding flags, which include a standards track RFC for 
non-private ones, I know where to find the semantics of such 
well-known flags. IMAP itself has no such constraints on the 
documentation of status flags (unless somewhere I missed a change to 
IMAP).
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 13:51:11 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin
> <[email-masked]> wrote:
>
> > Message status flags are extensible and have been since the inception of
> > IMAP.
> >
>
> Thats a good point and does imply another resolution to this issue: that is
> to remove message flags from annotations for now.

I like this variant (another alternative I like is to make ANNOTATE flags
read-only copies of corresponding IMAP flags and prohibit to send updates to
them via ANNOTATE).
However in order to keep common syntax for ANNOTATE and MODTIME, we must
reserve a entry prefix (dataset) for flags in ANNOTATE extension.

> We could write up
> $forwarded and $redirected (the only additional flags currently defined in
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags,
> if there was interest.

I agree. Actually $Forwarded was implemented by Execmail.

> We would still keep the body-part flags in ANNOTATE,
> of course.

Yes.
__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 11 Jul 2001 12:30:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 15:28:11 -0400, Cyrus Daboo wrote:
> Thats a good point and does imply another resolution to this issue: that is
> to remove message flags from annotations for now. We could write up
> $forwarded and $redirected (the only additional flags currently defined in
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags,
> if there was interest.

Exactly.  What's more, $Forwarded and $Redirected as traditional IMAP flags
will work with any existing server which offers \* (and most servers do).  So
no extension is needed to add these to IMAP.  I suspect that these can be
added with a small "write it and forget about it" RFC.

\Forwarded and \Redirected are also possible, but that would require clicking
up IMAP's major version.  Basically, \xxx flags are "required to be supported
by all servers with explicit knowledge" flags, as opposed to the $xxx flags
which exploit the IMAP keywords capability and don't require special server
knowledge.  I don't think that is within IMAPEXT's charter to add any \xxx
flags.

Date: Wed, 11 Jul 2001 15:28:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

--On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin 
<[email-masked]> wrote:

> Message status flags are extensible and have been since the inception of
> IMAP.
>

Thats a good point and does imply another resolution to this issue: that is 
to remove message flags from annotations for now. We could write up 
$forwarded and $redirected (the only additional flags currently defined in 
ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags, 
if there was interest. We would still keep the body-part flags in ANNOTATE, 
of course.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 12:00:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Pete Resnick <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 13:33:14 -0500, Pete Resnick wrote:
> Not really. Of course, you have the separate old code for dealing
> with old servers, but (like we did in Eudora when UIDL came along for
> POP) you stop maintaining the old code when adding new features.

UIDL was a last desperate attempt at an end-of-life kicker to POP to avoid
having to implement IMAP.  There is no evidence that IMAP is at that stage.

> >I can't think of a better way of guaranteeing that ANNOTATE will die
> >than by over-engineering such as duplicating already-present
> >functionality.
> Nonsense. It is a trivial change to the server, it benefits every
> client,

Please explain how you are able to determine what is a "trivial change to the
server" for every server, and what "benefits every client."  I have seen no
evidence that either claim is true.

> and it doesn't make an arbitrary distinction between "flags
> for message status" and "flags for message status that we decided
> were important back when we first wrote the protocol".

I can't believe that anyone who is familiar with the architecture of IMAP
would make such a statement.

Message status flags are extensible and have been since the inception of IMAP.

Date: Wed, 11 Jul 2001 13:33:14 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 10:13 AM -0700, Mark Crispin wrote:

>The history of other protocols shows that that will not happen.  You will have
>to have the code paths for FETCH/STORE forever.

Not really. Of course, you have the separate old code for dealing 
with old servers, but (like we did in Eudora when UIDL came along for 
POP) you stop maintaining the old code when adding new features. Yes, 
the old features continue to work with the old code, but the new 
features require the new server capability.

>I can't think of a better way of guaranteeing that ANNOTATE will die 
>than by over-engineering such as duplicating already-present 
>functionality.

Nonsense. It is a trivial change to the server, it benefits every 
client, and it doesn't make an arbitrary distinction between "flags 
for message status" and "flags for message status that we decided 
were important back when we first wrote the protocol". Things die 
much more quickly by under-engineering than by over-engineering.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 20:16:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Pete Resnick <[email-masked]>
> On 7/11/01 at 11:37 AM -0400, Cyrus Daboo wrote:
> 
> >Should ANNOTATE allow clients an alternative to using STORE/FETCH 
> >for standard IMAP flags?
> 
> I think it should. In the long run, clients would like to access all 
> message attributes through ANNOTATE and avoid having two separate 
> mechanisms (and code paths).

Is there an intention on the part of the IETF to eventually ("in the long
run") make certain extensions mandatory?

--Arnt

Date: Wed, 11 Jul 2001 10:13:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Pete Resnick <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 10:59:15 -0500, Pete Resnick wrote:
> I think it should. In the long run, clients would like to access all
> message attributes through ANNOTATE and avoid having two separate
> mechanisms (and code paths).

The history of other protocols shows that that will not happen.  You will have
to have the code paths for FETCH/STORE forever.

I can't think of a better way of guaranteeing that ANNOTATE will die than by
over-engineering such as duplicating already-present functionality.

Date: Wed, 11 Jul 2001 12:27:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

--On Wednesday, July 11, 2001 10:59 AM -0500 Pete Resnick 
<[email-masked]> wrote:

> I think it should. In the long run, clients would like to access all
> message attributes through ANNOTATE and avoid having two separate
> mechanisms (and code paths). I think that a server that implements
> ANNOTATE should:

But the server will always have to support two code paths for storing, 
responding, appending and searching using standard flags and keywords.

> I don't see what the problem is if the mailbox is open in more than one
> client.

This ties in somewhat with Issue #3: if one connected client is 
'annotate-aware' and another is not, the server has to be fully aware of 
that fact in order to know whether to send FLAGS or ANNOTATION responses 
(or both) as appropriate for each client. If we can decide how to deal with 
issue #3 then maybe that could be applied here, but we will have to write 
some detailed text explaining how to deal with responses for duplicated 
data in shared mailbox environments.

One option is to state:

Annotate-aware clients always receive flag state via ANNOTATION fetch 
responses (irrespective of whether STORE FLAGS or STORE ANNOTATION is 
used). Other clients always receive flag state via FLAGS fetch responses.

My biggest concern with allowing standard flags in ANNOTATIONS is that it 
could lead down a slippery slope by suggesting other standard IMAP data be 
exposed the same way - e.g. having an ANNOTATION that duplicates the 
ENVELOPE or BODYSTRUCTURE data.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 10:59:15 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 11:37 AM -0400, Cyrus Daboo wrote:

>Should ANNOTATE allow clients an alternative to using STORE/FETCH 
>for standard IMAP flags?

I think it should. In the long run, clients would like to access all 
message attributes through ANNOTATE and avoid having two separate 
mechanisms (and code paths). I think that a server that implements 
ANNOTATE should:

- Provide ANNOTATE mechanisms to access all message flags
- Update message flags for non-ANNOTATE clients when an ANNOTATE 
client updates them through ANNOTATE
- Update message flags for ANNOTATE clients when a non-ANNOTATE 
client updates them through STORE

>I think we should avoid duplicating the IMAP flags in annotate (i.e. 
>leave it as it is now). If it were duplicated, then a question 
>arises as to what responses a server should send when a mailbox is 
>simultaneously open in more than one client.

I don't see what the problem is if the mailbox is open in more than one client.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 11:51:20 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

Issue #4

Should there be a special ACL bit to indicate if annotations are shared or 
private by default for a mailbox (this is somewhat related to Open Issue 
#2)? And are the proposed ACL rights for determing 
read/write/shared/private annotation access acceptable - particularly 
overlaoding the 's' right for private annotation writes?

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:45:29 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Open Issue #3

Currently requires that ANNOTATION unsolicited responses not be sent until 
the client has issued at least one FETCH with an ANNOTATION fetch item. Is 
this prohibition really neccessary?

My personal opinion:

We should avoid sending annotation data unless the client has indicated in 
some way that it will actually use it. The approach of waiting for an 
ANNOTATION fetch seems reasonable. Another option would be to have a switch 
on the SELECT command to tell the server to return unsolicited ANNOTATION 
responses.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:41:40 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

Issue #2

Should annotation stores without a .priv or .shared suffix (i.e. to the 
'default') be allowed? This is dangerous because the client won't know for 
sure whether other users will be able to see the annotation later.

How a client learns or changes the default is also an open issue.  One 
suggestion is to use an additional ACL bit to indicate the current default 
state.

It may be better to remove the default, and force clients to always 
explicitly store into one or the other.

My personal opinion:

Only allow explicit use of .priv and .shared - no default - because of the 
added complexity of determining the default and being able to set it. Plus 
I believe clients would want to make sure that a user explicitly indicates 
shared or private for an annotation anyway.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:37:41 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Open Issue #1

Should ANNOTATE allow clients an alternative to using STORE/FETCH for 
standard IMAP flags? Currently the draft only defines some new flags 
(forwarded, redirected), but does not include the standard set.

My personal opinion:

I think we should avoid duplicating the IMAP flags in annotate (i.e. leave 
it as it is now). If it were duplicated, then a question arises as to what 
responses a server should send when a mailbox is simultaneously open in 
more than one client.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:32:10 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Current Issues for discussion
Sender: [email-masked]

Hi folks,
There are currently four 'open issues' in 
draft-ietf-imapext-annotate-01.txt. It would be good to address these 
before the meeting in London (and even better before the draft cut-off). I 
will post each one as a separate message to the list shortly.

If you have any other issues with ANNOTATE please post them to the list as 
well.

-- 
Cyrus Daboo

X-From_: [email-masked] Fri Jul 06 15:05:11 2001
Delivery-date: Fri, 06 Jul 2001 15:05:11 +0100
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-01.txt
Date: Fri, 06 Jul 2001 06:51:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-01.txt
	Pages		: 
	Date		: 05-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-01.txt
Date: Fri, 06 Jul 2001 06:51:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-01.txt
	Pages		: 
	Date		: 05-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-00.txt
Date: Thu, 05 Jul 2001 06:53:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-00.txt
	Pages		: 
	Date		: 03-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-00.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 3 Jul 2001 16:12:19 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Meeting in London
Sender: [email-masked]

We will be meeting in London. I have sent in the request. As soon as 
I hear back, I'll let you know when it is.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: Status of drafts?
Date: Tue, 3 Jul 2001 11:24:47 -0700
Sender: [email-masked]

> Also, what is the status of the following drafts that apparently have
> been deleted:
> LANGUAGE - draft-ietf-imapext-language
Alexey and myself submitted an updated draft in Feb 01.  Here is a current
link:

http://search.ietf.org/internet-drafts/draft-gahrns-imap-language-02.txt

Date: Tue, 03 Jul 2001 00:40:06 -0400
From: Cyrus Daboo <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, [email-masked]
Subject: Re: Status of drafts?
Sender: [email-masked]

--On Monday, July 2, 2001 9:15 PM -0700 "Paul Hoffman / IMC" 
<[email-masked]> wrote:

> COMMAND+ - draft-ietf-imapext-commandplus

This draft expired. There was no interest at the time in pursuing the ideas 
it outlined.

Also note that the VIEW draft has also expired, but its effectively been 
replaced by the new WINDOW draft, draft-ietf-imapext-window-00.txt, which 
was posted to the drafts repository a week ago.

-- 
Cyrus Daboo

Date: Mon, 2 Jul 2001 21:15:54 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Status of drafts?
Sender: [email-masked]

Greetings again. Alexey noticed that there are a bunch of broken 
links on the WG's web page at <http://www.imc.org/ietf-imapext/>.

Apparently there was a draft to update ACL, but it has expired. Is it 
being revived?

Also, what is the status of the following drafts that apparently have 
been deleted:

COMMAND+ - draft-ietf-imapext-commandplus
LANGUAGE - draft-ietf-imapext-language

Any updates to the page are welcome.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 31 Jul 2001 16:08:39 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: 51st IETF - Internet Message Access Protocol Extension WG
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 7/31/01 at 2:32 PM -0600, Alexey Melnikov wrote:

>What about CONDSTORE issues?

Consider it added.

>Is this the order of discussion?

Nope. Just a list. We generally figure out order when we get there.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 31 Jul 2001 14:32:01 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 51st IETF - Internet Message Access Protocol Extension WG
Sender: [email-masked]

[email-masked] wrote:

> Internet Message Access Protocol Extension WG (imapext)
>
> Monday, August 06 at 1930-2200
> ===============================
>
> CHAIR:  Pete Resnick <[email-masked]>
>
> AGENDA:
>
> - ANNOTATE issues

What about CONDSTORE issues?

> - New WINDOW proposal
> - LIST extensions
> - Status of SORT/THREAD
> - Status of ACL

Is this the order of discussion? If it is, I would rather move WINDOW to the end (because it
might take a lot of time), ACL to the beginning (because nothing was done so far with it),
LIST/SORT/THREAD to the beginning (they should be straightforward).

> The following will be discussed as time permits:
>
> - BINARY
> - The MULTIAPPEND/LITERAL+ debate
>
> Other items under discussion on the IMAPEXT mailing list may be added at the time of the m
> eeting.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Tue, 31 Jul 2001 15:21:01 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Proposal for ANNOTATEMORE extension
Sender: [email-masked]

Hi folks,
Since we're getting close to completing ANNOTATE (some issues are still
unresolved on the list), I'd like to propose an extension to add
annotations for mailboxes and the server. I'm calling this ANNOTATEMORE.

The idea with this is to allow annotations to be attached to each mailbox,
and for a set of 'global' annotations associated with the server itself.
Examples of use include a 'message of the day' server annotation, an
annotation on mailboxes indicating the default sort order to use when
displaying the mailbox to the user etc.

My proposal is to use the same entry/attribute/value data model that
ANNOTATE uses. In this case we would have /server and /mailbox/<mailbox
name> top level entries. We would have to have two new commands for reading
and writing annotations, and a new untagged response for returning the
annotation data, e.g.:

a SETANNOTATION ("/mailbox/INBOX/sort" ("value" "SUBJECT"))
a OK SETANNOTATION complete

a GETANNOTATION ("/server/motd" "value"))
* ANNOTATION ("/server/motd" ("value" "Server maintenance at 10 pm"))
a OK GETANNOTATION complete

I believe this is a logical extension to the message annotation capability
that ANNOTATE introduces, and there is already one server that has its own
equivalent of the server annotation mechanism, so it would be good to
standardise this.

I'm prepared to describe this in more detail in London next week, if we
agree to put it on the agenda.

Comments?

-- 
Cyrus Daboo

Date: Fri, 27 Jul 2001 17:52:51 -0700
From: Chris Newman <[email-masked]>
Subject: Re: MULTIAPPEND may be a mistake
To: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

If we start with a "TRANS=APPEND" extension which only permits APPEND 
commands to the same mailbox within a transaction, then my transaction 
proposal is almost identical in complexity to the MULTIAPPEND command.  We 
can add "TRANS=STORE" later if people feel it's too complex to do both IMAP 
write operations in one extension.

Rather than doing a one-off MULTIAPPEND command, let's recognize that 
MULTIAPPEND _is_ a transaction facility and should be designed as the first 
application of a transaction infrastructure in IMAP.

Transactions do get complex if they span mailboxes and support parallel 
simultaneous writes to the same mailbox, but those features can be deferred 
to a separate extension if we ever need them.

Perhaps we should call the commands:
	WRITEGROUP START
	WRITEGROUP CANCEL
	WRITEGROUP END
since I notice an irrational fear of the concept "transaction" in some 
circles.

		- Chris

--On Friday, July 27, 2001 11:41 -0700 Jutta Degener <[email-masked]> 
wrote:
> Nobody doubts that transactions would be nice to have, powerful
> transactions even nicer.  But they're not required for MULTIAPPEND,
> and they're tricky to implement in systems that don't already have them.
>
> MULTIAPPEND, since it's one command, can be handled in small systems
> by locking a mailbox, appending, and unlocking the mailbox.  As soon
> as you stretch the transaction period across multiple commands, you're
> opening a can of synchronization problems that IMAP has so far wisely
> stayed away from.
>
> Jutta <[email-masked]>
>

To: Lyndon Nerenberg <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, <[email-masked]>
Subject: Re: BINARY and CTE transformations
From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jul 2001 02:41:01 +0200
Lines: 17
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

>> Not only do you have to convert the data back to the original CTE, but you
>> must also ensure that the original MIME headers are exactly the same as
>> they were when the message was signed, including folding, case-sensitivity
>> of the CTE value etc. You'd have to find some way of encapsulating the
>> original MIME headers in the modified version to ensure this would work
>> reliably.
> 
> True enough, however I think this can be handled in a lightweight manner.
> (And it *must* be handled in a lightweight manner if this is going to
> catch on.)

Just curious, could you elaborate on the "lightweight manner"?
Servers that reformat MIME headers cause multipart/signed to break in
the real world today, so something that would solve this would surely
be appreciated, I think.

Date: Fri, 27 Jul 2001 15:24:04 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY and CTE transformations
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, July 27, 2001 15:02 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:
> But what standard is being violated? Transforming things that are signed
> or encrypted is asking for trouble, but it's not outright forbidden that
> I'm aware of.

multipart/signed applied to 8-bit and binary in any context where the 
message might go over SMTP is forbidden by RFC 1847.  I'd say the 
restriction on binary by inference applies to any 8-bit/non-binary 
transport and thus applies to IMAP.

> This issue is a major concern for us since we're generating large
> quantities of signed and encrypted content that gets sent out through
> software we have no control over. We have to assume there will be cases
> where CTE transformations *must* be applied to a message in order to
> deliver it to the end-user client software. CTE transformation is not evil
> in and of itself ... if the client can reconstitute the original CTE, and
> the CTE transformations are lossless, then the client can verify and
> decrypt the message even if it did get transformed along the way. Having a
> standardized way of discovering the original CTE is what makes this
> possible.

Yes, I think that would be an interesting approach.

		- Chris

Date: Fri, 27 Jul 2001 15:57:21 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: <[email-masked]>
Subject: Re: BINARY and CTE transformations
Sender: [email-masked]

> FYI The PGP/MIME specs (RFC2015, draft-ietf-openpgp-mime-08.txt) both state
> that signed data MUST be constrained to a 7bit CTE. The S/MIME message spec
> (RFC2633) has a similar MUST requirement, though it states this is only
> needed if the message is to go out on the internet. So technically one
> should never get multipart/signed data with a binary or 8bit CTE. In
> practice that may be different.

Okay, but my read on that is that you're required to _generate_ 7bit, but
they don't (and can't) outlaw what happens downstream. We're arguing
semantics, though :-)

> Not only do you have to convert the data back to the original CTE, but you
> must also ensure that the original MIME headers are exactly the same as
> they were when the message was signed, including folding, case-sensitivity
> of the CTE value etc. You'd have to find some way of encapsulating the
> original MIME headers in the modified version to ensure this would work
> reliably.

True enough, however I think this can be handled in a lightweight manner.
(And it *must* be handled in a lightweight manner if this is going to
catch on.)

--lyndon

Date: Fri, 27 Jul 2001 17:33:07 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY and CTE transformations
Sender: [email-masked]

--On Friday, July 27, 2001 3:02 PM -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> But what standard is being violated? Transforming things that are signed
> or encrypted is asking for trouble, but it's not outright forbidden that
> I'm aware of.

FYI The PGP/MIME specs (RFC2015, draft-ietf-openpgp-mime-08.txt) both state 
that signed data MUST be constrained to a 7bit CTE. The S/MIME message spec 
(RFC2633) has a similar MUST requirement, though it states this is only 
needed if the message is to go out on the internet. So technically one 
should never get multipart/signed data with a binary or 8bit CTE. In 
practice that may be different.

> This issue is a major concern for us since we're generating large
> quantities of signed and encrypted content that gets sent out through
> software we have no control over. We have to assume there will be cases
> where CTE transformations *must* be applied to a message in order to
> deliver it to the end-user client software. CTE transformation is not evil
> in and of itself ... if the client can reconstitute the original CTE, and
> the CTE transformations are lossless, then the client can verify and
> decrypt the message even if it did get transformed along the way. Having a
> standardized way of discovering the original CTE is what makes this
> possible.

Not only do you have to convert the data back to the original CTE, but you 
must also ensure that the original MIME headers are exactly the same as 
they were when the message was signed, including folding, case-sensitivity 
of the CTE value etc. You'd have to find some way of encapsulating the 
original MIME headers in the modified version to ensure this would work 
reliably.

-- 
Cyrus Daboo

Date: Fri, 27 Jul 2001 15:02:13 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: <[email-masked]>
Subject: BINARY and CTE transformations
Sender: [email-masked]

On Fri, 27 Jul 2001, Chris Newman wrote:

> I guess I can live with that, but please consider putting in some "servers
> MAY reject" language.  There are two camps in the IETF: "servers should
> enforce standards aggressively on interactive connections to deter
> standards creep" and "garbage in, garbage out".  There are server
> implementors in the former camp who will reject APPENDed messages which
> violate standards egregiously, so one may as well give the client
> implementors fair warning.

But what standard is being violated? Transforming things that are signed
or encrypted is asking for trouble, but it's not outright forbidden that
I'm aware of.

This issue is a major concern for us since we're generating large
quantities of signed and encrypted content that gets sent out through
software we have no control over. We have to assume there will be cases
where CTE transformations *must* be applied to a message in order to
deliver it to the end-user client software. CTE transformation is not evil
in and of itself ... if the client can reconstitute the original CTE, and
the CTE transformations are lossless, then the client can verify and
decrypt the message even if it did get transformed along the way. Having a
standardized way of discovering the original CTE is what makes this
possible.

If anyone wants to discuss this in London, drop me a note.

--lyndon

From: Steve Hole <[email-masked]>
Date: Fri, 27 Jul 2001 14:20:17 -0600
To: Lyndon Nerenberg <[email-masked]>
Subject: Re: BINARY version 3
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 27 Jul 2001 11:45:53 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> > (3) In section 5.4, I'd add: If an APPEND command contains a body part with 
> > a content-transfer-encoding of binary that is contained in the signed 
> > portion of a multipart/signed, the server MUST NOT alter the 
> > content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
> > "[CANT-CONVERT]" special information token.
> 
> This I have a problem with. I don't believe the server should be enforcing
> these kind of policy decisions on the clients behalf. Garbage in, garbage
> out. And this doesn't solve the problem of a multipart/signed binary CTE
> message being injected via LMTP with CHUNKING.

I agree.   The server certainly must accept a signed message with a CTE of
binary.   There are huge good reasons why this is a valid thing to want to
do, and may in fact be the driving force behind the binary requirement.
 
> The correct solution (which is outside the scope of this draft) is
> to label sections with the original CTE whenever a transformation is
> applied. I think I'll write up a draft to discuss this.

I don't know about that either.

The problem comes when a non BINARY capable client fetches the message or 
parts.   Then the server is faced with an issue.   As Lyndon notes, how 
the message got there is secondary, it now has to do something intelligent
with it.

And really, the exact case is when the client tries to fetch the MIME 
body structure that includes the signature blocks.   At that point it MUST 
convert, but it SHOULD issue some type of warning to the client letting it
know that content conversion was performed that will affect any signature 
security processing on the message.   Of course, fetching the entire 
rfc822 in this case would trigger this -- sigh ... Outlook.

In practice, this is not likely to be a big deal.   Anybody who uses 
BINARY is going to be do so in the presence of a complete BINARY solution 
that includes UA, MTA, and IMAP server.   They all pretty much will have 
to work together to get true BINARY stuff going in the general case.   
Becaue the Internet at large does not have good (if any really) binary 
support, this will likely be constrained to use in local infrastructure 
cases or special use like VPIM.   In either case, everything will be up to
snuff and it should work.   As things improve in the Internet in general, 
then those boundaries, enforced purely by new software deployment -- not 
standards, will expand.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 27 Jul 2001 12:42:44 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY version 3
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, July 27, 2001 11:45 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:
>> (3) In section 5.4, I'd add: If an APPEND command contains a body part
>> with  a content-transfer-encoding of binary that is contained in the
>> signed  portion of a multipart/signed, the server MUST NOT alter the
>> content-transfer-encoding and MAY (MUST?) reject the APPEND command with
>> a  "[CANT-CONVERT]" special information token.
>
> This I have a problem with. I don't believe the server should be enforcing
> these kind of policy decisions on the clients behalf. Garbage in, garbage
> out. And this doesn't solve the problem of a multipart/signed binary CTE
> message being injected via LMTP with CHUNKING.
>
> The correct solution (which is outside the scope of this draft) is
> to label sections with the original CTE whenever a transformation is
> applied. I think I'll write up a draft to discuss this.

I guess I can live with that, but please consider putting in some "servers 
MAY reject" language.  There are two camps in the IETF: "servers should 
enforce standards aggressively on interactive connections to deter 
standards creep" and "garbage in, garbage out".  There are server 
implementors in the former camp who will reject APPENDed messages which 
violate standards egregiously, so one may as well give the client 
implementors fair warning.

		- Chris

Date: Fri, 27 Jul 2001 11:41:05 -0700
From: Jutta Degener <[email-masked]>
Organization: Mediagate
To: IMAP Extensions WG <[email-masked]>
Subject: Re: MULTIAPPEND may be a mistake
Sender: [email-masked]

Nobody doubts that transactions would be nice to have, powerful
transactions even nicer.  But they're not required for MULTIAPPEND,
and they're tricky to implement in systems that don't already have them.

MULTIAPPEND, since it's one command, can be handled in small systems
by locking a mailbox, appending, and unlocking the mailbox.  As soon
as you stretch the transaction period across multiple commands, you're
opening a can of synchronization problems that IMAP has so far wisely
stayed away from.

Jutta <[email-masked]>

Date: Fri, 27 Jul 2001 10:43:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: imapv, multiappend, sort, and thread drafts
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Nobody bothered to tell me, and thus these drafts all expired this month.

I created versions with updated dates, which are on
	ftp://ftp.cac.washington.edu/mail/
but the internet-drafts bureaucracy won't accept them until August 14.

I would prefer not to hear any snide comments.

Organization: ACI Worldwide - Advanced Technology Group
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY version 3 
Date: Fri, 27 Jul 2001 11:45:53 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> (1) The MIME 8-bit content-transfer-encoding forbids NUL, so your example 
> in section 4 of 8-bit with NUL is not a valid example.

Oops.

> (2) The spec needs to explicitly mention the following scenario:
>   (A) BINARY aware client appends a message with CTE binary body part.
>   (B) Non-BINARY aware IMAP4 compliant client fetches that message.

> The only feasible way to deal with that scenario is for the server to act 
> as if the BINARY body part was actually base64 encoded to the client in 
> step B.  This impacts both the BODYSTRUCTURE and the actual BODY fetch.  An 
> important interoperability scenario.

Okay, I'll add text to call this out explicitly.

> (3) In section 5.4, I'd add: If an APPEND command contains a body part with 
> a content-transfer-encoding of binary that is contained in the signed 
> portion of a multipart/signed, the server MUST NOT alter the 
> content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
> "[CANT-CONVERT]" special information token.

This I have a problem with. I don't believe the server should be enforcing
these kind of policy decisions on the clients behalf. Garbage in, garbage
out. And this doesn't solve the problem of a multipart/signed binary CTE
message being injected via LMTP with CHUNKING.

The correct solution (which is outside the scope of this draft) is
to label sections with the original CTE whenever a transformation is
applied. I think I'll write up a draft to discuss this.

--lyndon

From: Edward Hibbert <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: RE: MULTIAPPEND may be a mistake
Date: Thu, 26 Jul 2001 09:24:10 +0100
Sender: [email-masked]

I haven't been following the MULTIAPPEND discussion closely, so I can't
comment on whether transactions would help there, but in general I am
strongly in favour of introducing them.  

I think it would help in a number of areas:
- We've had discussions about an atomic MOVE command.  Transactions open up
the possibility of achieving this without introducing a separate command.
- I would be in favour of going further and covering multiple mailboxes; I
know of clients which attempt to set up (and delete) multiple related
messages in multiple mailboxes, and get confused if things go wrong partway
through.  Of course those clients could be better written to cope with those
cases, but I think the problem is that the lack of a transactional mechanism
forces over-complicated processing into the clients.  I'd rather force it
into the server instead :-).
- I think it might help with the problem that the conditional store
extension is attempting to solve too, though I've not been following that
closely enough to be sure.

It's always dangerous to argue from a particular implementation, but we
already have a (cross-mailbox) transaction mechanism which fits naturally
with this.

However we'd need to talk carefully about locking; presumably a TRANSACTION
START locks a mailbox exclusively against other modifications?

Regards,

Edward Hibbert
Internet Applications Group
Data Connection Ltd
Tel:	+44 131 662 1212		Fax:	+44 131 662 1345
Email:	[email-masked]	Web:	http://www.dataconnection.com

-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 12:10 AM
To: IMAP Extensions WG
Subject: MULTIAPPEND may be a mistake

I have been thinking a lot about MULTIAPPEND and I believe it is a mistake.

My counter proposal is to add three commands to IMAP:

	TRANSACTION START
	TRANSACTION END
	TRANSACTION CANCEL

These modify the behavior of STORE and APPEND such that the "OK" response 
to those commands mean the result is successful so far, but has not 
necessarily been committed.  Certain commands (EXPUNGE, SELECT, EXAMINE, 
UNSELECT) would not be permitted during a transaction (they would either 
fail with a BAD or cancel the transaction, not sure which the spec should 
say).  All commands within a TRANSACTION must apply to the same mailbox. 
All write operations within a TRANSACTION are completed in order.

This is only marginally more difficult to implement on the server side than 
MULTIAPPEND since it adds flags to the mix, but is much more powerful.  In 
addition to providing all the functionality of MULTIAPPEND, this massively 
simplifies the error recovery for a disconnected client replaying its cache.

Furthermore, there are three desirable properties when doing bulk APPENDs:

	* atomicity
	* keep the pipe full (no stalling for a round trip)
	* server can report an error in the middle

The combination of MULTIAPPEND and LITERAL+ can only accomplish two of 
these three properties at a time.  The combination of TRANSACTION and 
LITERAL+ can accomplish all three at the same time.

I also think TRANSACTION may be simpler to retrofit into clients which 
already do bulk APPENDs.

		- Chris

Date: Wed, 25 Jul 2001 23:11:07 -0400
From: Tony Hansen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

And even on Unix, it depends on the filesystem implementation. All you
might need is a stat(2).

	Tony

Chris Newman wrote:
> 
> --On Wednesday, July 25, 2001 8:42 -0700 Mark Crispin
> <[email-masked]> wrote:
> > It needs to be emphasized that is NOT a cheap operation if the hierarchy
> > is based upon a filesystem. In the case of %, the directory has to be opened and
> > examined. ...
> 
> It depends on which filesystem.  For example, on a MacOS filesystem it adds
> no overhead.
> 
>                 - Chris

Date: Wed, 25 Jul 2001 16:10:29 -0700
From: Chris Newman <[email-masked]>
Subject: MULTIAPPEND may be a mistake
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have been thinking a lot about MULTIAPPEND and I believe it is a mistake.

My counter proposal is to add three commands to IMAP:

	TRANSACTION START
	TRANSACTION END
	TRANSACTION CANCEL

These modify the behavior of STORE and APPEND such that the "OK" response 
to those commands mean the result is successful so far, but has not 
necessarily been committed.  Certain commands (EXPUNGE, SELECT, EXAMINE, 
UNSELECT) would not be permitted during a transaction (they would either 
fail with a BAD or cancel the transaction, not sure which the spec should 
say).  All commands within a TRANSACTION must apply to the same mailbox. 
All write operations within a TRANSACTION are completed in order.

This is only marginally more difficult to implement on the server side than 
MULTIAPPEND since it adds flags to the mix, but is much more powerful.  In 
addition to providing all the functionality of MULTIAPPEND, this massively 
simplifies the error recovery for a disconnected client replaying its cache.

Furthermore, there are three desirable properties when doing bulk APPENDs:

	* atomicity
	* keep the pipe full (no stalling for a round trip)
	* server can report an error in the middle

The combination of MULTIAPPEND and LITERAL+ can only accomplish two of 
these three properties at a time.  The combination of TRANSACTION and 
LITERAL+ can accomplish all three at the same time.

I also think TRANSACTION may be simpler to retrofit into clients which 
already do bulk APPENDs.

		- Chris

Date: Wed, 25 Jul 2001 15:22:23 -0700
From: Chris Newman <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
To: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

--On Wednesday, July 25, 2001 8:42 -0700 Mark Crispin 
<[email-masked]> wrote:
> It needs to be emphasized that is NOT a cheap operation if the hierarchy
> is based upon a filesystem.

It depends on which filesystem.  For example, on a MacOS filesystem it adds 
no overhead.

		- Chris

Date: Wed, 25 Jul 2001 08:42:36 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

On Wed, 25 Jul 2001 09:15:43 -0400, Barry Leiba wrote:
> > I'll probably have LIST/LSUB always return the CHILDREN flags (they
> > are very inexpensive).
> The reason for having the client ask for it is not to save bytes (though I
> suppose it's reasonable to do that), but to give the sever the option of
> avoiding the overhead if the client doesn't want the information.  If it's
> pretty much free for your server to do it, you may certainly return the
> flags even when they're not requested.

It needs to be emphasized that is NOT a cheap operation if the hierarchy is
based upon a filesystem.  In the case of %, the directory has to be opened and
examined.  Since that's what some clients do now anyway, I'm not opposed to
indicating children, but want the option of not doing so unless the client
asks for it.

Of course, in the case of *, children flags are completely unnecessary since
it will be obvious from the output whether or not there are children!  [Think
about this.]

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Date: Wed, 25 Jul 2001 09:15:43 -0400
Sender: [email-masked]

> there are any clients which currently look for \Has[No]Children.  If so,
> then I'll probably have LIST/LSUB always return the CHILDREN flags (they
> are very inexpensive).  Otherwise, I'll leave it selectable via LISTEXT,
> to reduce the number of bytes sent to the client.

The reason for having the client ask for it is not to save bytes (though I
suppose it's reasonable to do that), but to give the sever the option of
avoiding the overhead if the client doesn't want the information.  If it's
pretty much free for your server to do it, you may certainly return the 
flags even when they're not requested.  The number of extra bytes is minimal,
except in very long lists.

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 24 Jul 2001 22:05:27 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

Barry Leiba wrote:
> 

[...]

> > 4. Are there any existing clients which implement standalone CHILDREN
> > (draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
> > advertising it in addition to LISTEXT, or should any new CHILDREN
> > implementations do so only under the LISTEXT umbrella?
> 
> As CHILDREN evolved, it was actually decided NOT to advertise a capability
> string for it, because as the draft was written there was no way to ask
> for the info or not.  So a client could determine that it was supported by
> the presence of the flags.

OK, that simplifies things a little.  I'm still curious about whether
there are any clients which currently look for \Has[No]Children.  If so,
then I'll probably have LIST/LSUB always return the CHILDREN flags (they
are very inexpensive).  Otherwise, I'll leave it selectable via LISTEXT,
to reduce the number of bytes sent to the client.

Thoughts?

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 15:22:38 -0400
Sender: [email-masked]

> 1. The discussion of \PlaceHolder incorrectly refers to \NoSelect
> instead of \Noselect.

Atoms are case-insensitive.

> 2. The second example uses the option SUBSCRIBE instead of SUBSCRIBED.

Already fixed in my draft, along with the erroneous reference to
"SUBSCRIPTIONS" later.

> 1. Is \NonExistent ONLY intended to be used for subscribed mailboxes, or
> can/should it be used for other mailboxes in the hierarchy.  For
> example, we have a subscribed mailbox foo/bar, but mailbox foo doesn't
> exist.  Should LIST (SUBSCRIBED) "" % return
> 
> * LIST (\NonExistent \PlaceHolder) "/" "foo"
> 
> or should \Noselect be used in place of \Nonexistent?  Or, is just
> \PlaceHolder sufficient?

I'd say that \NonExistent should be used in any case where it's possible
to have an entity returned that doesn't exist.  So if "a/b/c/d/e" is 
subscribed to, and nothing in the whole hierarchy exists, then whenever
there's cause to return "a" or "a/b" or "a/b/c" or "a/b/c/d", they should
also be marked \NonExistent.  Theoretically, this would apply in cases
other than with the SUBSCRIBED option, but there aren't any other cases
where this could happen (since we don't allow truly missing hierarchy
levels; we can only mark those \Noselect).

Since the SUBSCRIBED option demands that all flags be accurate, you'd
need to return both flags... because both are true.

> 2. What should the flags be for a LIST response which returns just a
> namespace prefix?  For instance, given the namespace
> 
> * NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))
> 
> and assuming that we have mailbox "Shared Folders/foo" which is
> subscribed and exists, should LIST (SUBSCRIBED) " % return
> 
> * LIST (\Noselect \PlaceHolder) "/" "Shared Folders"
> 
> or should it return only one or the other?  Should \NonExistent be used
> in place of \Noselect?

I think a namespace is an existent entity, so it gets marked \Noselect.

> 3. When doing a LIST (SUBSCRIBED CHILDREN), does the presence of
> \PlaceHolder imply \HasChildren, or should both flags be returned (ala
> \Noinferiors implies and supercedes \HasNoChildren)?

Clearly \PlaceHolder implies \HasChildren, but I see no reason not to send
them both.  If anyone feels strongly about it, I'm happy to say that because
\PlaceHolder implies \HasChildren, the latter SHOULD NOT be returned.  But
I won't make that change unless some people really think I should.

> 4. Are there any existing clients which implement standalone CHILDREN
> (draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
> advertising it in addition to LISTEXT, or should any new CHILDREN
> implementations do so only under the LISTEXT umbrella?

As CHILDREN evolved, it was actually decided NOT to advertise a capability
string for it, because as the draft was written there was no way to ask 
for the info or not.  So a client could determine that it was supported by
the presence of the flags.

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shapira-snap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shapira-snap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shapira-snap-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 24 Jul 2001 01:08:30 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: New revision of CONDSTORE draft (conditional store)
Sender: [email-masked]

In July I've submitted two revisions of conditional store extension
(CONDSTORE).
Current draft is named draft-melnikov-imap-condstore-02.txt.

Here is the list of changes:
Changes from -01 to -02:
     1.  Added MODTIME data item to STATUS command.
     2.  Added OK untagged response to SELECT/EXAMINE.
     3.  Clarified that MODIFIED response code contains list of UIDs for
          conditional UID STORE and message set for STORE.
     4.  Added per-message modtime.
     5.  Added PERFLAGMODTIME capability.
     6.  Fixed several bugs in examples.
     7.  Added more comments to ABNF.

    Changes from -00 to -01:
     1.  Refreshed the list of Open Issues.
     2.  Changed "attr-name" to "entry-name", because modtime applies to
entry,
           not attribute.
     3.  Added MODTIME untagged response.
     4.  Cleaned up ABNF.
     5.  Added "Acknowledgments" section.
     6.  Fixed some spelling mistakes.

List of open issues:

    1). How specify different UNCHANGESINCE for different flags in the
          same STORE?  Do we want such granularity anyway?

    2). The document assumes that each flag has a corresponding
          ANNOTATE entry. This has to be synchronized with ANNOTATE draft.

    3). "If the "modtime" of any metadata item specified in STORE
         operation for any message in the message set is greater
         than the unchangedsince value, then the store fails with a
         MODIFIED response code that includes message set of all
         messages that failed UNCHANGESINCE test."

        This basically means that server must continue conditional store
          operation to find all messages for which test fails. Is it
          reasonable, or should the text be changed from "all messages" to
          "at least one message".

    4). MODTIME Untagged Response specifies a message set modtime applies
to.
          Can anybody think of a reason why it is a bad idea? Message set
          is not really required, because MODTIME untagged response must
          follow corresponding untagged FETCH responses.
        Should we use UID set instead?

    5). Should SEARCH MODTIME require MODTIME untagged response?

          SEARCH doesn't cause updates, unless they are the result of some
          other operation. However SEARCH MODTIME forces server to read
          modtime, so server can report this information anyway.

    6). Add support for SORT extension?

I've also implemented revision 2 of the draft in our server, so I can share
my experience.

Comments?
__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Mon, 23 Jul 2001 16:37:10 -0700
From: Chris Newman <[email-masked]>
Subject: Re: BINARY version 3
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

The binary draft (-04) is looking great, but it needs a bit more 
wordsmithing:

(1) The MIME 8-bit content-transfer-encoding forbids NUL, so your example 
in section 4 of 8-bit with NUL is not a valid example.

(2) The spec needs to explicitly mention the following scenario:
  (A) BINARY aware client appends a message with CTE binary body part.
  (B) Non-BINARY aware IMAP4 compliant client fetches that message.

The only feasible way to deal with that scenario is for the server to act 
as if the BINARY body part was actually base64 encoded to the client in 
step B.  This impacts both the BODYSTRUCTURE and the actual BODY fetch.  An 
important interoperability scenario.

(3) In section 5.4, I'd add: If an APPEND command contains a body part with 
a content-transfer-encoding of binary that is contained in the signed 
portion of a multipart/signed, the server MUST NOT alter the 
content-transfer-encoding and MAY (MUST?) reject the APPEND command with a 
"[CANT-CONVERT]" special information token.

		- Chris

--On Friday, May 18, 2001 15:24 -0600 Lyndon Nerenberg 
<[email-masked]> wrote:

> I've submitted the -03 revision to the I-D editor. You can take an
> early peek via:
>
>  http://research.messagingdirect.com/draft-nerenberg-imap-binary-03.txt
>
> The major change is the replacement of the horrid BINARYSTRUCTURE goop
> with the new BINARY.SIZE attribute.
>
> --lyndon

Date: Mon, 23 Jul 2001 16:31:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

Just for kicks, I started hacking a LISTEXT/LIST-SUBSCRIBED
implementation for Cyrus and came across a couple of nits and a couple
of questions.

Nits:

1. The discussion of \PlaceHolder incorrectly refers to \NoSelect
instead of \Noselect.

2. The second example uses the option SUBSCRIBE instead of SUBSCRIBED.

Questions:

1. Is \NonExistent ONLY intended to be used for subscribed mailboxes, or
can/should it be used for other mailboxes in the hierarchy.  For
example, we have a subscribed mailbox foo/bar, but mailbox foo doesn't
exist.  Should LIST (SUBSCRIBED) "" % return

* LIST (\NonExistent \PlaceHolder) "/" "foo"

or should \Noselect be used in place of \Nonexistent?  Or, is just
\PlaceHolder sufficient?

2. What should the flags be for a LIST response which returns just a
namespace prefix?  For instance, given the namespace

* NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))

and assuming that we have mailbox "Shared Folders/foo" which is
subscribed and exists, should LIST (SUBSCRIBED) " % return

* LIST (\Noselect \PlaceHolder) "/" "Shared Folders"

or should it return only one or the other?  Should \NonExistent be used
in place of \Noselect?

3. When doing a LIST (SUBSCRIBED CHILDREN), does the presence of
\PlaceHolder imply \HasChildren, or should both flags be returned (ala
\Noinferiors implies and supercedes \HasNoChildren)?

4. Are there any existing clients which implement standalone CHILDREN
(draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
advertising it in addition to LISTEXT, or should any new CHILDREN
implementations do so only under the LISTEXT umbrella?

Thanks,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: [email-masked]
cc: [email-masked]
Subject: draft-segmuller-imap-structure-00
Organization: ACI Worldwide - Advanced Technology Group
Date: Fri, 20 Jul 2001 14:56:26 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

Wolfgang, would it not make more sense to return _all_ the MIME
header information? If we need to query for something besides a
content-* header, we have to fall back to the old way of doing it,
or define a new extension to retrieve the new headers. The current
scope is much to narrow I think.  Generalizing it to return all
the MIME headers would make it much more useful.

If you do extend it to return all the MIME header information then
I would also suggest changing the fetch attribute name to MIMESTRUCTURE,
to better describe what is being requested.

--lyndon

Date: Fri, 20 Jul 2001 16:29:40 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

FYI, there appears to be a typo in the options syntax which uses the
token "SUBSCRIPTIONS".

BTW, have any client vendors implemented this yet?  I've been looking
this over and I can add it to Cyrus with a couple of hours work, but I
don't want to take the time if there are no clients to test with and/or
the draft isn't stable yet.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: Steve Hole <[email-masked]>
Date: Fri, 20 Jul 2001 12:14:56 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

On Fri, 20 Jul 2001 11:21:18 -0400 Barry Leiba <[email-masked]> 
wrote:

> 
> > Presumably, the SUBSCRIPTIONS option requires that the server return full
> > information about folders that are subscribed, unlike LSUB which just
> > returns a list of subscribed folders.
> 
> Hm.  If you only say "presumably", then I haven't made it clear enough; I 
> thought I had.  Should I put more words in, clearer words, or what?  Do you 
> have any specific phrasing for a certain spot that you think will raise it 
> from "Presumably," to "I clearly see that"?

Actually, (1) I only scanned it, and (2) I wanted to point out this bit 
specifically to the list.

So, I don't believe there is any clarification action required.
 
Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 20 Jul 2001 11:21:18 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

> Presumably, the SUBSCRIPTIONS option requires that the server return full
> information about folders that are subscribed, unlike LSUB which just
> returns a list of subscribed folders.

Hm.  If you only say "presumably", then I haven't made it clear enough; I 
thought I had.  Should I put more words in, clearer words, or what?  Do you 
have any specific phrasing for a certain spot that you think will raise it 
from "Presumably," to "I clearly see that"?

> My God, I hope that nobody actually reads that sentence above that doesn't
> have a long history with IMAP, because it will just be the dumbest
> sounding thing in the history of mankind.

:-)

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Fri, 20 Jul 2001 09:16:32 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-01.txt
Cc: IMAP extensions Mailing List <[email-masked]>
Sender: [email-masked]

Presumably, the SUBSCRIPTIONS option requires that the server return full 
information about folders that are subscribed, unlike LSUB which just 
returns a list of subscribed folders.

My God, I hope that nobody actually reads that sentence above that doesn't
have a long history with IMAP, because it will just be the dumbest 
sounding thing in the history of mankind.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 19 Jul 2001 13:38:59 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-01.txt
Sender: [email-masked]

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

Hi all.  Sorry for the horrid delay in this; I've just submitted the 
attached update to the I-D editor.  I believe it covers the LIST extensions 
issues we discussed way back when, and sorts out the items that were in 
contention.  I think we should submit enhanced selection criteria as a 
separate extension, based on these basic LIST extensions, and I'll be happy 
to do that if we want to talk about them at the upcoming IETF meeting (ah, 
assuming I get approval for the travel).  We can start discussing them here.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

--==========618440821==========
Content-Type: text/plain; charset=us-ascii;
 name="draft-ietf-imapext-list-extensions-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-01.txt"; size=18441

IMAP Extensions Working Group                                   B. Leiba
Internet Draft                           IBM T.J. Watson Research Center
Document: draft-ietf-imapext-list-extensions-01.txt            July 2001
                                                    Expires January 2002

                     IMAP4 LIST Command Extensions

Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.

   A revised version of this draft document will be submitted to the RFC
   editor as an Proposed Standard for the Internet Community. 
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].  This document will expire before 31
   January 2002.  Distribution of this memo is unlimited.

1. Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   add extensions that require specialized lists (see [MboxRefer] for an
   example) we expand the number of list commands, as each extension
   must add its function to both LIST and LSUB.  This document describes
   extensions to the LIST command that allow these additions to be done
   in mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

B. Leiba                  Expires January 2002                  [Page
1]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

2. Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].

3. Introduction

   The extensions to the LIST command will be accomplished by amending
   the syntax to allow options to be specified.  The list of options
   will replace the several commands that are currently used to mix and
   match the information requested.  The new syntax is backward-
   compatible, with no ambiguity: if the first word after the command
   name begins with a parenthesis, the new syntax is being used; if it
   does not, it's in the original syntax.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB commands
   described in [MboxRefer].  We are also defining the mechanism to
   request extended mailbox information, such as is described in the
   now-expired "Child Mailbox Extension" draft [ChildMbox].  The base
   LSUB command is not deprecated by this extension; rather, this
   extension adds a way to obtain subscription information with more
   options, with those server implementations that support it.  Clients
   that simply need a list of subscribed mailboxes, as provided by the
   LSUB command, SHOULD continue to use that command.

4. LIST Command Options

   The LIST command syntax is extended by adding a parenthesized list of
   command options between the command name and the reference name (see
   the formal syntax in section 6 for specific details).  Command
   options will be defined in this document and in approved extension
   documents; each option will be enabled by a capability string (one
   capability may enable multiple options), and a client MUST NOT send
   an option for which the server has not advertised support.  A server
   MAY ignore options it does not recognize.

   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  This document also defines the "LIST-
   SUBSCRIBED" capability string; see the "SUBSCRIBED" option below.

B. Leiba                  Expires January 2002                  [Page 2]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   The options defined in this specification are

       SUBSCRIBED - causes the LIST command to list subscribed
          mailboxes, rather than the actual mailboxes.  This will often
          be a subset of the actual mailboxes.  It's also possible for
          this list to contain the names of mailboxes that don't exist. 
          In any case, the list MUST include exactly those mailbox names
          that match the selection criteria and are subscribed to.  This
          option is intended to supplement the LSUB command, and support
          for it is optional -- a server that supports the SUBSCRIBED
          option indicates so through the LIST-SUBSCRIBED capability.

          Of particular note are the mailbox flags as returned by this
          option, compared with what is returned by LSUB.  With the
          latter, the flags returned may not reflect the actual flag
          status on the mailbox, and the \NoSelect flag has a special
          meaning (it indicates that this mailbox is not, itself,
          subscribed, but that it has child mailboxes that are).  With
          the SUBSCRIBED option described here, the flags are accurate
          and complete, and have no special meanings.

          "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
          and some servers must do significant extra work to respond to
          "LIST (SUBSCRIBED)".  Because of this, clients SHOULD continue
          to use "LSUB" unless they specifically want the additional
          information offered by "LIST (SUBSCRIBED)".  At the same time,
          servers SHOULD support the LIST-SUBSCRIBED capability even if
          it entails extra work, because a client that wants the
          information will still obtain it by using LSUB followed by a
          series of LIST commands, so servers might as well make it
          easier.

          This option defines a new mailbox flag, "\NonExistent", that
          indicates that a mailbox is subscribed to, but does not
          actually exist.  The "\NonExistent" flag MUST be supported and
          MUST be accurately computed.

       REMOTE - causes the LIST command to show remote mailboxes as
          well as local ones, as described in [MboxRefer].  This option
          is intended to replace the RLIST command and, in conjunction
          with the SUBSCRIBED option, the RLSUB command.  This option is
          only available on servers that also support RFC-2193.

       CHILDREN - Requests mailbox child information as originally
          proposed in [ChildMbox].  See section 5, below, for details. 
          Support for this is optional, but this option MUST be accepted
          by all servers (though it MAY be ignored).

   The LISTEXT capability also defines a new mailbox flag,

B. Leiba                  Expires January 2002                  [Page 3]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   "\PlaceHolder", that indicates that the designated mailbox does not
   meet the selection criteria of the given LIST command, but that it
   has one or more child mailboxes that do [EDITORIAL NOTE: "might"?]. 
   The LSUB command indicates this condition by using the "\NoSelect"
   flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   "\PlaceHolder" flag is more general, in that it can be used with any
   extended set of selection criteria.

5. The CHILDREN Option

   The CHILDREN option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [ChildMbox].  The CHILDREN
   option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified, or MAY ignore the option entirely.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.   When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.

   The Child Mailbox Extension provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST '' * or a LIST '' % for each mailbox name.

   The Child Mailbox Extension defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren. 
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN option is provided to indicate that the client
   particularly wants this information.  If the CHILDREN option is
   present, the server SHOULD return these attributes even if their
   computation is expensive.

\HasChildren - The presence of this attribute indicates that the mailbox
       has child mailboxes.

       A server SHOULD NOT set this attribute if there are child
       mailboxes, and the user does not have permissions to access any
       of them. In this case, \HasNoChildren SHOULD be used.

B. Leiba                  Expires January 2002                  [Page 4]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

       In many cases, however, a server may not be able to efficiently
       compute whether a user has access to all child mailboxes.  As
       such a client MUST be prepared to accept the \HasChildren
       attribute as a hint.  That is, a mailbox MAY be flagged with the
       \HasChildren attribute, but no child mailboxes will appear in
       the LIST response.

\HasNoChildren - The presence of this attribute indicates that the
       mailbox has NO child mailboxes that are accessible to the
       currently authenticated user.

   In some instances a server that supports the Child Mailbox Extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.

   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute.  In particular, some
   servers may not be able to combine the SUBSCRIBED and CHILDREN
   options.  Such servers MUST honour the SUBSCRIBED option, and they
   will simply ignore the CHILDREN option if both are requested.

   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in a LIST response.

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

6. Examples

   The first example shows the complete local hierarchy that will be
   used for the other examples.

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

B. Leiba                  Expires January 2002                  [Page 5]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   In the next example, we'll see the subscribed mailboxes.  This is
   similar, but not equivalent, to <LSUB "" "*">.  Note that the mailbox
   called "Fruit/Peach" is subscribed to, but does not actually exist
   (perhaps it was deleted while still subscribed).  And the "Fruit"
   mailbox is not subscribed to, but it has two subscribed children.

       C: A02 LIST (SUBSCRIBE) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\PlaceHolder) "/" "Fruit"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST (\NonExistent) "/" "Fruit/Peach"
       S: A02 OK done

   The next example shows the use of the CHILDREN option.  The client,
   without having to list the second level of hierarchy, now knows which
   of the top-level mailboxes have sub-mailboxes (children) and which do
   not.  Note that it's not necessary for the server to return the
   \HasNoChildren flag for the inbox, because the \NoInferiors flag
   already implies that, and has a stronger meaning.

       C: A03 LIST (CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: A03 OK done

   In this example we see more mailboxes, which reside on another server
   to which we may obtain referrals.  This is similar to the command
   <RLIST "" "%">.  We also see the mixing of two options.  Note that in
   the case of the remote mailboxes, the server might or might not be
   able to include CHILDREN information; it includes it if it can, and
   omits it if it can't.

       C: A04 LIST (REMOTE CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: * LIST () "/" "Bread"
       S: * LIST (\HasChildren) "/" "Meat"
       S: A04 OK done

7. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

B. Leiba                  Expires January 2002                  [Page 6]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   child-mbox-flag = "\HasChildren" / "\HasNoChildren"
                      ; flags for Child Mailbox Extension, at most one
                      ; possible per LIST response

   list            = "LIST" [SP list-options] SP mailbox SP list-mailbox

   list-options     = "(" [option *(SP option)] ")"

   mbox-list-oflag := child-mbox-flag / "\NonExistent" / "\PlaceHolder"

   option           = "SUBSCRIPTIONS" / "CHILDREN" / "REMOTE" /
                     option-extension

   option-extension = atom

8. Security Considerations

   This document describes syntactic changes to the specification of the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  They
   are described in [IMAP4] and [MboxRefer].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.   In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

9. References

   [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.

   [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193;
   Microsoft Corporation; September 1997.

B. Leiba                  Expires January 2002                  [Page
7]

Internet DRAFT       IMAP4 LIST Command Extensions         October 2000

   [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension";
   draft-gahrns-imap-child-mailbox-03.txt; Microsoft Corporation;
   November 1997 -- expired, listed for historical reference.

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

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

10. Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in section 5, is theirs.

11. Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

   Phone: 1-914-784-7941
   Email: [email-masked]

B. Leiba                  Expires January 2002     
            [Page 8]
--==========618440821==========--

Date: Thu, 19 Jul 2001 17:58:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Steve Hole <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

By definition, the notications may be divided into the set of interesting
ones and the set of uninteresting ones. One of the sets may be empty in
any given case, but conceptually they exist.

A flood happens if the set of uninteresting notifications is "big" and the
server is sending them to the client.

My intuition says that the set of interesting notifications is closely
related to the set of interesting unsolicited flag updates, to the set of
unsolicited EXPUNGE responses, and so on. Whatever a client is interested
in: If it doesn't want EXPUNGEs for message 1234, it probably won't want
ANNOTATIONs for it either, and vice versa.

If that's right, then ANNOTATION should follow the WINDOW (or similar
mechanism) just like e.g. EXPUNGE does, and that's all there is to it.
Nothing ANNOTATE-specific.

--Arnt

From: Steve Hole <[email-masked]>
Date: Thu, 19 Jul 2001 08:56:22 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 18 Jul 2001 19:16:55 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> One more point to note on this particular issue. One benefit to having 
> flags in ANNOTATE is that it allows splitting the flags into per-user 
> (private) and shared components, so it would be possible to have a per-user 
> answered flag, for example. Of course this also confuses the situation 
> because we would have to specify what happens with conventional IMAP flags 
> wrt storing private or shared.

Make them private by default like any other metadata.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Thu, 19 Jul 2001 08:49:34 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1.1 Build (10) 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"

On Wed, 18 Jul 2001 19:11:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> Another approach is to say that an unsolicited change to an annotation can 
> only be sent if that annotation itself has been previously requested in a 
> FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited 
> changes to /a/b/c, but not to /a/b/d. Thus a client can effectively 
> 'subscribe' to specific annotation changes by doing a fetch for those 
> annotations only.

That means holding an awful lot of state in server though.   I'm not sure 
that as a server author I would like the business logic of this.   
Thinking about it, I don't believe that you will get a flood of changes.  
The general case will be that you are the only one ever modifying the 
state, so and you want the notifications anyway.   If it is much rarer 
shared mailbox situation, you will be getting notifications, but they are 
by definition going to be notifications on shared annotations which seems 
fine as well.   Things like helpdesk mailboxes would seem to require this.

I would keep it simple.   Ask for any annotation, start getting responses.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 19 Jul 2001 01:19:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Steve Hole <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Cyrus Daboo wrote:

> There is also a question of what level of granularity we want for turning
> on the unsolicited notifications. Right now its set so that ANY annotation
> fetch will cause changes to ALL annotations to be sent unsolicited.
>
> Another approach is to say that an unsolicited change to an annotation can
> only be sent if that annotation itself has been previously requested in a
> FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited
> changes to /a/b/c, but not to /a/b/d. Thus a client can effectively
> 'subscribe' to specific annotation changes by doing a fetch for those
> annotations only.

This can [potentially] consume a lot of memory on server side. (Probably not as
match as WINDOW, but nevertheless)

Also, in this case it is probably better to have additional command to request
interest in some annotation tree. With you approach, there is no way to cancel
notifications for an annotation if the annotation is fetched once.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 19 Jul 2001 01:12:13 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Cyrus Daboo wrote:

> Open Issue #3
>
> Currently requires that ANNOTATION unsolicited responses not be sent until
> the client has issued at least one FETCH with an ANNOTATION fetch item. Is
> this prohibition really neccessary?
>
> My personal opinion:
>
> We should avoid sending annotation data unless the client has indicated in
> some way that it will actually use it. The approach of waiting for an
> ANNOTATION fetch seems reasonable. Another option would be to have a switch
> on the SELECT command to tell the server to return unsolicited ANNOTATION
> responses.

I like the idea of implicit enabling of ANNOTATION responses.

I also like the idea of not sending annotation data itself, just send a
notification that some annotation changed (Proposed by Jutta originally if I am
not mistaken).

Adding restriction on annotation size (and maybe untagged reply on select that
reports the limit) seams like a good idea too.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 19 Jul 2001 01:05:10 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mike Gahrns <[email-masked]>
CC: Steve Hole <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

Mike Gahrns wrote:

> Steve Hole writes:
> > I think that, if we have a default, that default should be to store as a
> > private annotation.
> *** Yes, I strongly concur with Steve here.
>
> However, I still question whether there is a need for a default.   Are
> annotations going to be that frequent of operation that the cost of sending
> these few bytes are worth the complexity of defining a default?  I suppose
> if things like normal flag manipulations end up in annotations then this may
> be worth considering, but if annotations are limited to the odd annotation
> on message I doubt whether adding a default is worth it.

I agree with Mike, I would prefer being explicit all the time and have no
default.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

From: "Mike Gahrns" <[email-masked]>
To: "Steve Hole" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: "IMAP Extensions" <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Date: Wed, 18 Jul 2001 17:40:20 -0700
Sender: [email-masked]

Steve Hole writes:
> I think that, if we have a default, that default should be to store as a
> private annotation.
*** Yes, I strongly concur with Steve here.

However, I still question whether there is a need for a default.   Are
annotations going to be that frequent of operation that the cost of sending
these few bytes are worth the complexity of defining a default?  I suppose
if things like normal flag manipulations end up in annotations then this may
be worth considering, but if annotations are limited to the odd annotation
on message I doubt whether adding a default is worth it.

Date: Wed, 18 Jul 2001 19:16:55 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

One more point to note on this particular issue. One benefit to having 
flags in ANNOTATE is that it allows splitting the flags into per-user 
(private) and shared components, so it would be possible to have a per-user 
answered flag, for example. Of course this also confuses the situation 
because we would have to specify what happens with conventional IMAP flags 
wrt storing private or shared.

-- 
Cyrus Daboo

Date: Wed, 18 Jul 2001 19:11:20 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

--On Wednesday, July 18, 2001 04:46:55 PM -0600 Steve Hole 
<[email-masked]> wrote:

>> We should avoid sending annotation data unless the client has indicated
>> in  some way that it will actually use it. The approach of waiting for
>> an  ANNOTATION fetch seems reasonable. Another option would be to have a
>> switch  on the SELECT command to tell the server to return unsolicited
>> ANNOTATION  responses.
>
> I agree.   Note that this is effectively an implicit mode, that is entered
> when ANNOTATION data is requested.   I personally don't have a problem
> with modal behaviour of this type, but others have indicated that they
> don't like it.   I view it as a reasonable optimization.

There is also a question of what level of granularity we want for turning 
on the unsolicited notifications. Right now its set so that ANY annotation 
fetch will cause changes to ALL annotations to be sent unsolicited.

Another approach is to say that an unsolicited change to an annotation can 
only be sent if that annotation itself has been previously requested in a 
FETCH. i.e. If I fetch annotation /a/b/c, then I will get unsolicited 
changes to /a/b/c, but not to /a/b/d. Thus a client can effectively 
'subscribe' to specific annotation changes by doing a fetch for those 
annotations only.

The only reason I propose this is that I'm concerned about a client being 
flooded with annotation changes for annotations it doesn't care about (e.g. 
ones in another vendor's namespace). Given that ANNOTATE doesn't currently 
recommend a maximum size for annotation data (maybe that's something it 
should do) the potential for floods of unsolicted responses on a heavily 
used shared mailbox is fairly large.

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:54:39 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 18 Jul 2001 18:57:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> In that case would we need to define .priv as a suffix at all as it 
> would be redundant? We would only need .shared.

Sounds right.

> So, removing .priv (leaving .shared), and having the default be private 
> seems reasonable to me. We just have to make it clear that if the user 
> isn't allowed to store a private annotation, then storing to default MUST 
> fail (i.e. it MUST NOT add it as a shared annotation). I guess that falls 
> under the security considerations.

Yep.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Wed, 18 Jul 2001 18:57:20 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

--On Wednesday, July 18, 2001 04:44:26 PM -0600 Steve Hole 
<[email-masked]> wrote:

>> How a client learns or changes the default is also an open issue.  One
>> suggestion is to use an additional ACL bit to indicate the current
>> default  state.
>
> Don't worry about it.   Fix the default as private and make pubishing to a
> shared (public) scope always be explicit.

In that case would we need to define .priv as a suffix at all as it would 
be redundant? We would only need .shared.

So, removing .priv (leaving .shared), and having the default be private 
seems reasonable to me. We just have to make it clear that if the user 
isn't allowed to store a private annotation, then storing to default MUST 
fail (i.e. it MUST NOT add it as a shared annotation). I guess that falls 
under the security considerations.

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:50:13 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:51:20 -0400 Cyrus Daboo <[email-masked]> wrote:

> Issue #4
> 
> Should there be a special ACL bit to indicate if annotations are shared or 
> private by default for a mailbox (this is somewhat related to Open Issue 

No.

> #2)? And are the proposed ACL rights for determing 
> read/write/shared/private annotation access acceptable - particularly 
> overlaoding the 's' right for private annotation writes?

Setting access independent rights for the shared and private instances of 
an annotation seems fine.   If one interprets the "s" right as the 
"metadata update right", then certainly annotations qualifies as metadata 
and that seems fine.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:46:55 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:45:29 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> Open Issue #3
> 
> Currently requires that ANNOTATION unsolicited responses not be sent until 
> the client has issued at least one FETCH with an ANNOTATION fetch item. Is 
> this prohibition really neccessary?
> 
> My personal opinion:
> 
> We should avoid sending annotation data unless the client has indicated in 
> some way that it will actually use it. The approach of waiting for an 
> ANNOTATION fetch seems reasonable. Another option would be to have a switch 
> on the SELECT command to tell the server to return unsolicited ANNOTATION 
> responses.

I agree.   Note that this is effectively an implicit mode, that is entered
when ANNOTATION data is requested.   I personally don't have a problem 
with modal behaviour of this type, but others have indicated that they 
don't like it.   I view it as a reasonable optimization.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Wed, 18 Jul 2001 16:44:26 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #2 attribute suffix default
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 11:41:40 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> Issue #2
> 
> Should annotation stores without a .priv or .shared suffix (i.e. to the 
> 'default') be allowed? This is dangerous because the client won't know for 
> sure whether other users will be able to see the annotation later.

I think that, if we have a default, that default should be to store as a 
private annotation.   My reasoning is simple.   Storing something 
sensitive inadvertently as a shared annotation is potentially disastrous 
ie. loss of job, loss of spouse, death by mafia, imprisonment etc.    
Storing something inadvertently as a private annotation may result in 
badness, but the badness is likely to be things like application failure, 
non-communication etc.    I just believe that the downside results 
inadvertent visibility to the public substantially outweighs the 
alternative.

So

1.  Let them store explicitly to either a .priv or a .shared suffix.

2.  Implicit storage scope is always private.

> How a client learns or changes the default is also an open issue.  One 
> suggestion is to use an additional ACL bit to indicate the current default 
> state.

Don't worry about it.   Fix the default as private and make pubishing to a
shared (public) scope always be explicit.
 
> It may be better to remove the default, and force clients to always 
> explicitly store into one or the other.
> 
> 
> My personal opinion:
> 
> Only allow explicit use of .priv and .shared - no default - because of the 
> added complexity of determining the default and being able to set it. Plus 
> I believe clients would want to make sure that a user explicitly indicates 
> shared or private for an annotation anyway.

I would buy this too.   Either this or with the addition of the fixed 
default of private is fine by me.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Sun, 15 Jul 2001 20:59:19 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #5 Problem with STATUS ABNF in IMAP4rev1
Sender: [email-masked]

[Found this when adding HIGHESTMODTIME status data item to CONDSTORE
extension]

First of all I am not sure whether this is just a cut and paste bug in
ANNOTATE draft, but I found couple references to STATUS, including some
pieces of ABNF. Probably all references to STATUS should be removed from
ANNOTATE, as CONDSTORE already has this functionality.

Anyway,  ANNOTATE and/or CONDSTORE extension have the following problem:

>From IMAPrev1 ABNF:

   mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
                      "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number)
/
                      "STATUS" SP mailbox SP "("
                      [status-att SP number *(SP status-att SP number)]
")" /
                      number SP "EXISTS" / number SP "RECENT"

>From ANNOTATE:

   status            =/ "ANNOTATION-MODTIME"
                       ; modifies original IMAP4 STATUS command

and
   modtime has ACAP syntax.

If you have a close look at ABNF for mailbox-data, you notice that a
value of any status-att can be only a number.  Mark, can you relax this?
I need to be able to use at least "quoted" or "atom" (probably atom).

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 13 Jul 2001 11:22:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

--On Friday, July 13, 2001 12:36 AM -0600 Alexey Melnikov 
<[email-masked]> wrote:

>> Issue #4
>>
>> Should there be a special ACL bit to indicate if annotations are shared
>> or private by default for a mailbox (this is somewhat related to Open
>> Issue
>> # 2)? And are the proposed ACL rights for determing
>> read/write/shared/private annotation access acceptable - particularly
>> overlaoding the 's' right for private annotation writes?
>
> I was objecting to using "s" ACL right before. I don't think we should
> overload its well defined meaning.
> IMHO, we should introduce a new right for that, for example "W" (as
> opposed to "w").

I tend to agree. In which case I think ANNOTATE should explicitly require 
that a server that also does ACL, provide the 'W' bit.

-- 
Cyrus Daboo

Date: Fri, 13 Jul 2001 00:36:06 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

Cyrus Daboo wrote:

> Issue #4
>
> Should there be a special ACL bit to indicate if annotations are shared or
> private by default for a mailbox (this is somewhat related to Open Issue
> #2)? And are the proposed ACL rights for determing
> read/write/shared/private annotation access acceptable - particularly
> overlaoding the 's' right for private annotation writes?

I was objecting to using "s" ACL right before. I don't think we should
overload its well defined meaning.
IMHO, we should introduce a new right for that, for example "W" (as opposed to
"w").

Alexey

From: Steve Hole <[email-masked]>
Date: Wed, 11 Jul 2001 17:24:25 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 15:28:11 -0400 Cyrus Daboo <[email-masked]> wrote:

> 
> --On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
> 
> > Message status flags are extensible and have been since the inception of
> > IMAP.
> >
> 
> Thats a good point and does imply another resolution to this issue: that is 
> to remove message flags from annotations for now. We could write up 
> $forwarded and $redirected (the only additional flags currently defined in 
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags, 
> if there was interest. We would still keep the body-part flags in ANNOTATE, 
> of course.

This is really the issue.

If there is a concept of standard-flags-associated-only-with-annotate then
to get the "complete" flag set in a full functionality client, you have to
ask for both.   Not to mention that it is just plain confusing as hell!   
I don't believe it would pass the laugh test from someone who is new to 
IMAP looking at it.

Either

1.  Have all flags exposed in both or

2.  Have flags (binary metadata) exposed only in the store command.

I'm not strongly inclined either way actually, although I do tend toward 
the "both" side.   My reasons:

 * Annotate supports managing arbitrary per-message metadata.

 * Clearly, flags are binary metadata and the store command is a 
   command restricted to arbitrary binary metadata.

 * Annotate clearly could provide a more general mechanism for managing 
   all of the existing binary metadata as well as new metadata.

Of course, the "it could" argument is not a hugely strong argument.   I 
have always preferred general models to specific models though.

The reasons stated that supporting the both model are:

1.   It means maintaining two code paths to the same data in the server.

2.   The client is forced to detect which command set to use to get access
to the data.

3.   ???? (please fill in more that I have missed)

I would say to address the issues that are enumerated above:

1.   Managing arbitrary per-message meta data in server is likely to be 
non-trivial.   It will certainly be more difficult for some that for 
others.   In our case, for example, all of our metadata is held in a 
database that is already out-of-band of the message itself.   As a result,
while not trivial, it is not particularly difficult to do either.   
Supporting the two code paths in response to a fetch would be easy after 
the metadata storage extensions.   Supporting the unsolicited metadata 
notifications wouldn't be that hard because we already have a notification
posting system that is generally focused on metadata rather than just on 
flags.   To issue simultaneous ANNOTATE and FLAGS unsolicited responses is
not that big a deal.

The question is - how do you decide as the server to issue both or just 
ANNOTATE (more efficient) responses.   There would have to be a way to 
indicate "just do ANNOTATE please" to the server, and that is somewhat 
blech.

2.  Multiple code paths in the client, I'm going to claim, is actually 
pretty easy.   Hell, the c-client had simple fallback code for a long time
from IMAP4 to IMAP2bis.    Ours has numerous instances of fallback code 
based on tests for the existence/non-existence of a capability.   Things 
that come to mind immediately are referrals and ACL's.   The behaviour 
changes (for efficiency purposes) based on whether those things exist or 
not.    I could certainly imagine where I would conditionally excercise 
the ANNOTATE extension in preference to the base STORE and FETCH FLAGS.   
I can easily imagine where this would be done in the c-client as well.

As well, the client shouldn't actually care all that much about receiving 
FLAGS and ANNOTATE responses from the server, even though receiving both 
would be inefficient.   If both were issued, you would get redundant cache
updates as you processed both unsolicited responses.

So ...

Based on the objections I've heard so far, I think that you could do the 
both model IF you can find a way to engage "send ANNOTATE instead of 
FLAGS responses".   If not, it is much more messy.

Perhaps simply issuing a fetch for annotations would be enough to engage 
it.   This is an implicit mode, which most people will probably barf on.

Perhaps an explicit, command to engage it.  Once again, modal behaviour 
though.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Wed, 11 Jul 2001 16:11:41 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 12:00 PM -0700, Mark Crispin wrote:

>On Wed, 11 Jul 2001 13:33:14 -0500, Pete Resnick wrote:
>>  Not really. Of course, you have the separate old code for dealing
>>  with old servers, but (like we did in Eudora when UIDL came along for
>>  POP) you stop maintaining the old code when adding new features.
>
>UIDL

Was an example of a protocol extension that caused us to have two 
different code paths. I can name others if you like. The point (which 
you missed) was that having an extension that addresses a particular 
need may allow you to avoid continuing to develop code paths that do 
the same thing in a less general way.

>  > Nonsense. It is a trivial change to the server, it benefits every
>  > client,
>
>Please explain how you are able to determine what is a "trivial change to the
>server" for every server, and what "benefits every client."

Servers:

A server must keep track of flag changed for connected clients now. 
To map "change this annotation" to "change this annotation *and* 
change this flag" and vice-versa is architecturally simple. Yes, it 
is possible that servers are written that make this hard, but I would 
say those would be poorly architected servers.

Clients:

Allowing clients to use a single mechanism for similar functions is 
simplifying. Whether or not all clients immediately benefit from this 
is not what I am talking about; I'm talking about allowing clients to 
take advantage of a simplification being beneficial.

>I have seen no evidence that either claim is true.

I'm not at all sure what kind of evidence you might be referring to.

>  > and it doesn't make an arbitrary distinction between "flags
>>  for message status" and "flags for message status that we decided
>>  were important back when we first wrote the protocol".
>
>I can't believe that anyone who is familiar with the architecture of IMAP
>would make such a statement.
>
>Message status flags are extensible and have been since the inception of IMAP.

Their extensibility is completely dependent on the server 
implementation. Extensibility in ANNOTATE (as I understand it) is 
built-in; as a client I can create any flag I want, whether or not 
the server knows about it. And because ANNOTATE is very clear on the 
requirements of adding flags, which include a standards track RFC for 
non-private ones, I know where to find the semantics of such 
well-known flags. IMAP itself has no such constraints on the 
documentation of status flags (unless somewhere I missed a change to 
IMAP).
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 13:51:11 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin
> <[email-masked]> wrote:
>
> > Message status flags are extensible and have been since the inception of
> > IMAP.
> >
>
> Thats a good point and does imply another resolution to this issue: that is
> to remove message flags from annotations for now.

I like this variant (another alternative I like is to make ANNOTATE flags
read-only copies of corresponding IMAP flags and prohibit to send updates to
them via ANNOTATE).
However in order to keep common syntax for ANNOTATE and MODTIME, we must
reserve a entry prefix (dataset) for flags in ANNOTATE extension.

> We could write up
> $forwarded and $redirected (the only additional flags currently defined in
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags,
> if there was interest.

I agree. Actually $Forwarded was implemented by Execmail.

> We would still keep the body-part flags in ANNOTATE,
> of course.

Yes.
__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 11 Jul 2001 12:30:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 15:28:11 -0400, Cyrus Daboo wrote:
> Thats a good point and does imply another resolution to this issue: that is
> to remove message flags from annotations for now. We could write up
> $forwarded and $redirected (the only additional flags currently defined in
> ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags,
> if there was interest.

Exactly.  What's more, $Forwarded and $Redirected as traditional IMAP flags
will work with any existing server which offers \* (and most servers do).  So
no extension is needed to add these to IMAP.  I suspect that these can be
added with a small "write it and forget about it" RFC.

\Forwarded and \Redirected are also possible, but that would require clicking
up IMAP's major version.  Basically, \xxx flags are "required to be supported
by all servers with explicit knowledge" flags, as opposed to the $xxx flags
which exploit the IMAP keywords capability and don't require special server
knowledge.  I don't think that is within IMAPEXT's charter to add any \xxx
flags.

Date: Wed, 11 Jul 2001 15:28:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

--On Wednesday, July 11, 2001 12:00 PM -0700 Mark Crispin 
<[email-masked]> wrote:

> Message status flags are extensible and have been since the inception of
> IMAP.
>

Thats a good point and does imply another resolution to this issue: that is 
to remove message flags from annotations for now. We could write up 
$forwarded and $redirected (the only additional flags currently defined in 
ANNOTATE) as a separate draft defining those as 'traditional' IMAP flags, 
if there was interest. We would still keep the body-part flags in ANNOTATE, 
of course.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 12:00:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Pete Resnick <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 13:33:14 -0500, Pete Resnick wrote:
> Not really. Of course, you have the separate old code for dealing
> with old servers, but (like we did in Eudora when UIDL came along for
> POP) you stop maintaining the old code when adding new features.

UIDL was a last desperate attempt at an end-of-life kicker to POP to avoid
having to implement IMAP.  There is no evidence that IMAP is at that stage.

> >I can't think of a better way of guaranteeing that ANNOTATE will die
> >than by over-engineering such as duplicating already-present
> >functionality.
> Nonsense. It is a trivial change to the server, it benefits every
> client,

Please explain how you are able to determine what is a "trivial change to the
server" for every server, and what "benefits every client."  I have seen no
evidence that either claim is true.

> and it doesn't make an arbitrary distinction between "flags
> for message status" and "flags for message status that we decided
> were important back when we first wrote the protocol".

I can't believe that anyone who is familiar with the architecture of IMAP
would make such a statement.

Message status flags are extensible and have been since the inception of IMAP.

Date: Wed, 11 Jul 2001 13:33:14 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 10:13 AM -0700, Mark Crispin wrote:

>The history of other protocols shows that that will not happen.  You will have
>to have the code paths for FETCH/STORE forever.

Not really. Of course, you have the separate old code for dealing 
with old servers, but (like we did in Eudora when UIDL came along for 
POP) you stop maintaining the old code when adding new features. Yes, 
the old features continue to work with the old code, but the new 
features require the new server capability.

>I can't think of a better way of guaranteeing that ANNOTATE will die 
>than by over-engineering such as duplicating already-present 
>functionality.

Nonsense. It is a trivial change to the server, it benefits every 
client, and it doesn't make an arbitrary distinction between "flags 
for message status" and "flags for message status that we decided 
were important back when we first wrote the protocol". Things die 
much more quickly by under-engineering than by over-engineering.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 20:16:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Pete Resnick <[email-masked]>
> On 7/11/01 at 11:37 AM -0400, Cyrus Daboo wrote:
> 
> >Should ANNOTATE allow clients an alternative to using STORE/FETCH 
> >for standard IMAP flags?
> 
> I think it should. In the long run, clients would like to access all 
> message attributes through ANNOTATE and avoid having two separate 
> mechanisms (and code paths).

Is there an intention on the part of the IETF to eventually ("in the long
run") make certain extensions mandatory?

--Arnt

Date: Wed, 11 Jul 2001 10:13:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
To: Pete Resnick <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed, 11 Jul 2001 10:59:15 -0500, Pete Resnick wrote:
> I think it should. In the long run, clients would like to access all
> message attributes through ANNOTATE and avoid having two separate
> mechanisms (and code paths).

The history of other protocols shows that that will not happen.  You will have
to have the code paths for FETCH/STORE forever.

I can't think of a better way of guaranteeing that ANNOTATE will die than by
over-engineering such as duplicating already-present functionality.

Date: Wed, 11 Jul 2001 12:27:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

--On Wednesday, July 11, 2001 10:59 AM -0500 Pete Resnick 
<[email-masked]> wrote:

> I think it should. In the long run, clients would like to access all
> message attributes through ANNOTATE and avoid having two separate
> mechanisms (and code paths). I think that a server that implements
> ANNOTATE should:

But the server will always have to support two code paths for storing, 
responding, appending and searching using standard flags and keywords.

> I don't see what the problem is if the mailbox is open in more than one
> client.

This ties in somewhat with Issue #3: if one connected client is 
'annotate-aware' and another is not, the server has to be fully aware of 
that fact in order to know whether to send FLAGS or ANNOTATION responses 
(or both) as appropriate for each client. If we can decide how to deal with 
issue #3 then maybe that could be applied here, but we will have to write 
some detailed text explaining how to deal with responses for duplicated 
data in shared mailbox environments.

One option is to state:

Annotate-aware clients always receive flag state via ANNOTATION fetch 
responses (irrespective of whether STORE FLAGS or STORE ANNOTATION is 
used). Other clients always receive flag state via FLAGS fetch responses.

My biggest concern with allowing standard flags in ANNOTATIONS is that it 
could lead down a slippery slope by suggesting other standard IMAP data be 
exposed the same way - e.g. having an ANNOTATION that duplicates the 
ENVELOPE or BODYSTRUCTURE data.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 10:59:15 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ANNOTATE] Issue #1 duplication of IMAP flags
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On 7/11/01 at 11:37 AM -0400, Cyrus Daboo wrote:

>Should ANNOTATE allow clients an alternative to using STORE/FETCH 
>for standard IMAP flags?

I think it should. In the long run, clients would like to access all 
message attributes through ANNOTATE and avoid having two separate 
mechanisms (and code paths). I think that a server that implements 
ANNOTATE should:

- Provide ANNOTATE mechanisms to access all message flags
- Update message flags for non-ANNOTATE clients when an ANNOTATE 
client updates them through ANNOTATE
- Update message flags for ANNOTATE clients when a non-ANNOTATE 
client updates them through STORE

>I think we should avoid duplicating the IMAP flags in annotate (i.e. 
>leave it as it is now). If it were duplicated, then a question 
>arises as to what responses a server should send when a mailbox is 
>simultaneously open in more than one client.

I don't see what the problem is if the mailbox is open in more than one client.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 11 Jul 2001 11:51:20 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #4 ACLs for annotations
Sender: [email-masked]

Issue #4

Should there be a special ACL bit to indicate if annotations are shared or 
private by default for a mailbox (this is somewhat related to Open Issue 
#2)? And are the proposed ACL rights for determing 
read/write/shared/private annotation access acceptable - particularly 
overlaoding the 's' right for private annotation writes?

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:45:29 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Issue #3 unsolicited ANNOTATION responses
Sender: [email-masked]

Open Issue #3

Currently requires that ANNOTATION unsolicited responses not be sent until 
the client has issued at least one FETCH with an ANNOTATION fetch item. Is 
this prohibition really neccessary?

My personal opinion:

We should avoid sending annotation data unless the client has indicated in 
some way that it will actually use it. The approach of waiting for an 
ANNOTATION fetch seems reasonable. Another option would be to have a switch 
on the SELECT command to tell the server to return unsolicited ANNOTATION 
responses.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:41:40 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE]: Issue #2 attribute suffix default
Sender: [email-masked]

Issue #2

Should annotation stores without a .priv or .shared suffix (i.e. to the 
'default') be allowed? This is dangerous because the client won't know for 
sure whether other users will be able to see the annotation later.

How a client learns or changes the default is also an open issue.  One 
suggestion is to use an additional ACL bit to indicate the current default 
state.

It may be better to remove the default, and force clients to always 
explicitly store into one or the other.

My personal opinion:

Only allow explicit use of .priv and .shared - no default - because of the 
added complexity of determining the default and being able to set it. Plus 
I believe clients would want to make sure that a user explicitly indicates 
shared or private for an annotation anyway.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:37:41 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Issue #1 duplication of IMAP flags
Sender: [email-masked]

Open Issue #1

Should ANNOTATE allow clients an alternative to using STORE/FETCH for 
standard IMAP flags? Currently the draft only defines some new flags 
(forwarded, redirected), but does not include the standard set.

My personal opinion:

I think we should avoid duplicating the IMAP flags in annotate (i.e. leave 
it as it is now). If it were duplicated, then a question arises as to what 
responses a server should send when a mailbox is simultaneously open in 
more than one client.

-- 
Cyrus Daboo

Date: Wed, 11 Jul 2001 11:32:10 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: [ANNOTATE] Current Issues for discussion
Sender: [email-masked]

Hi folks,
There are currently four 'open issues' in 
draft-ietf-imapext-annotate-01.txt. It would be good to address these 
before the meeting in London (and even better before the draft cut-off). I 
will post each one as a separate message to the list shortly.

If you have any other issues with ANNOTATE please post them to the list as 
well.

-- 
Cyrus Daboo

X-From_: [email-masked] Fri Jul 06 15:05:11 2001
Delivery-date: Fri, 06 Jul 2001 15:05:11 +0100
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-01.txt
Date: Fri, 06 Jul 2001 06:51:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-01.txt
	Pages		: 
	Date		: 05-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-01.txt
Date: Fri, 06 Jul 2001 06:51:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-01.txt
	Pages		: 
	Date		: 05-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-00.txt
Date: Thu, 05 Jul 2001 06:53:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-00.txt
	Pages		: 
	Date		: 03-Jul-01
	
There is a class of applications that wish to have multiple IMAP clients
coordinate activities with a single shared mailbox. These applications
need some mechanism to synchronize state changes for messages within the
mailbox. They must be able to guaranty that only one client can change
message state (e.g. message flags or annotations) at any point in time.
An example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-condstore-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-condstore-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-00.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 3 Jul 2001 16:12:19 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Meeting in London
Sender: [email-masked]

We will be meeting in London. I have sent in the request. As soon as 
I hear back, I'll let you know when it is.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: Status of drafts?
Date: Tue, 3 Jul 2001 11:24:47 -0700
Sender: [email-masked]

> Also, what is the status of the following drafts that apparently have
> been deleted:
> LANGUAGE - draft-ietf-imapext-language
Alexey and myself submitted an updated draft in Feb 01.  Here is a current
link:

http://search.ietf.org/internet-drafts/draft-gahrns-imap-language-02.txt

Date: Tue, 03 Jul 2001 00:40:06 -0400
From: Cyrus Daboo <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, [email-masked]
Subject: Re: Status of drafts?
Sender: [email-masked]

--On Monday, July 2, 2001 9:15 PM -0700 "Paul Hoffman / IMC" 
<[email-masked]> wrote:

> COMMAND+ - draft-ietf-imapext-commandplus

This draft expired. There was no interest at the time in pursuing the ideas 
it outlined.

Also note that the VIEW draft has also expired, but its effectively been 
replaced by the new WINDOW draft, draft-ietf-imapext-window-00.txt, which 
was posted to the drafts repository a week ago.

-- 
Cyrus Daboo

Date: Mon, 2 Jul 2001 21:15:54 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Status of drafts?
Sender: [email-masked]

Greetings again. Alexey noticed that there are a bunch of broken 
links on the WG's web page at <http://www.imc.org/ietf-imapext/>.

Apparently there was a draft to update ACL, but it has expired. Is it 
being revived?

Also, what is the status of the following drafts that apparently have 
been deleted:

COMMAND+ - draft-ietf-imapext-commandplus
LANGUAGE - draft-ietf-imapext-language

Any updates to the page are welcome.

--Paul Hoffman, Director
--Internet Mail Consortium