Subject: AD review comments on draft-ietf-imapext-sort-13.txt
From: [email-masked]
To: [email-masked]
Date: Mon, 24 Nov 2003 10:35:12 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

This documents defines two threading algorithms, ORDEREDSUBJECT and REFERENCES,
and the IANA considerations section makes it sound like there's a registry for
threading algorithms with these as the two initial entries. However, this
document doesn't actually define such a registry. I see two possibilities here:
There are only two threading algorithms, end of story, no registry needed and
hence the text about this in the IANA considerations section needs to be
removed (unlikely), or else this document creates a new registry for threading
algorithms with these two as the initial entries. If it is the latter there
needs to be text added to define the registry and explain what the registration
procedures are (RFC required, first come first serve, etc.). 

In the "Sent Date" section, the procedure implied by "adjusted by time zone"
needs to be spelled out in a little more detail lest we end up with some
"creative" interpretations and corresponding implementations. It might also
make sense to discuss how to handle a date field with an invalid time zone
specification.

In the discussion of the charset argument for SORT and THREAD, reference is
made to the charset argument to SEARCH defined in the base specification, but
this document doesn't actually come out and specify that the semantics of SORT
and THREAD's charset argument are the same as that for SEARCH's. I suggest
adding a sentence along the lines of "The charset argument indicates the
[CHARSET] of the strings that appear in the {sort|thread} criteria." to the
relevant sections. The [CHARSET] reference would also need to be added to the
normative references.

The section containing the ABNF needs to state that it employs ABNF productions
defined in RFC 3501.

In the ABNF, change "; CHARSET argument to MUST be registered with IANA" to
read "; CHARSET values MUST be registered with IANA"

The RFC Editor views abstracts as essentially separate from the document
propoer. As such, it is usually necessary to have both an Abstract describing
the document as a whole very tersely and a separate introduction to the
specification that describes its purpose in a bit more detail.

The paragraph on MUST/SHOULD/MAY/etc. conventions needs to be moved to a
section of its own separate from the abstract.

The paragraph discussing capability announcment of the SORT and THREAD
extensions also needs to be moved to a separate section.

This document doesn't contain either the copyright or the IPR
boilerplate required by RFC 2026. 

The section numbering in this document is, well, strange. Most sections aren't
numbered, but then near the end up pops a section 12 and appendix A. I
understand the desire to want to use section numbers to align the command and
response material with RFC 3501, but I don't think this obviates the need for
the rest of the document to have sensible section numbers. Here's an alternate
suggestion: For the sections intended to be "inserted" into RFFC 3501, preface
the section numbers with "BASE." or something similar. Then number the various
other sections  of this document normally. 

That's it!

				Ned

Date: Sat, 15 Nov 2003 10:51:20 -0600
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

Hi Rob,

--On Friday, November 14, 2003 18:41 -0500 Rob Siemborski 
<[email-masked]> wrote:

| Comments?

As a general comment I would support a split to two ACL mechanisms: a 
simple one and a complex one (the later being based on the existing ACL). I 
think ACL2 has become too unwieldy in trying to support arbitrary ACL 
models and will ultimately prove to be a huge hurdle to implementation on 
the client (which is the end that potentially has to support the multitude 
of server models that can exist). It was pointed out in the meeting that 
WebDAV seems to suffer from that problem - the server's model is over 
generalized and its hard for a client to get all the possible options right 
- interop is poor.

So I think Rob is on the right track - we need an ACL+ to update the 
existing ACL spec. Then a simple Read-Only/Read-Write ACL model extension. 
The two need to co-exist, but a server may support only one, though I think 
we should recommend an ACL+ server also support PERMISSIONS.

Of course this does mean writing off the current ACL2 spec (though much of 
the work for ACL+ has been done in ACL2). There are also other extensions 
that have a dependency on ACL and those would need to be held up until we 
can decide what to do (I'm primarily thinking about ANNOTATE here). That's 
probably not something Pete wants to hear - but I think we can get 
ACL+PERMISSIONS done quickly - and it would probably be faster than trying 
to resolve all the issues with ACL2's arbitrary models.

It also means effectively having two ACL extensions rather than one. The 
question is whether the IESG would push-back on that - we need to get input 
from the ADs on that matter before we can decide whether to go ahead with 
this. Clearly we would pitch this as a simplification of this work - 
cutting down an arbitrary ACL model implementation (with many possible 
models) to two fixed models, which should make implementations and security 
analysis etc much easier to accomplish.

-- 
Cyrus Daboo

Date: Fri, 14 Nov 2003 19:26:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

Hi Rob -

This is an interesting idea.  Give me some time to mull it over.  This may
be the way out!

-- Mark --

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

Date: Fri, 14 Nov 2003 18:41:14 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Yet another ACL Strawman
Sender: [email-masked]

After the IMAPext meeting I spoke with some people and got to thinking if
there was a way we could come up with a way to do IMAP sharing that will
satisfy both the enterprise people who need detailed ACL support, and those
who feel the need to implement permissions with limited backend support
(e.g. UNIX file permissions).  Ideally, such a mechanism would be simple to
implement and not have complexity problems getting past the IESG.

I'd like to propose the following as a strawman INSTEAD of the
current ACL2 draft (or whatever ACL2 became after the last round of
comments):

Create an ACL+ capability that does the following:

  * Can only be advertised if ACL is advertised
  * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE)
bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2)

There may be other changes from ACL2 that I missed here, but the general
goal is "do the minimum required to fix ACL".  This may imply changing how
the namespace of identifiers are treated as well (e.g. user=foo,
group=bar), but I'd really like to keep the changes as minimal as possible
here if we can.

Create a new PERMISSIONS capability that works along the lines of the
following:

  * Define four bits you can set on a mailbox: owner read/write and
anyone read/write.  Have a command other than the ACL manipulation
commands that can manipulate/report these.

If a server advertises *both* PERMISSIONS and ACL, then it must also
advertise ACL+.  Also, the PERMISSIONS bits are tied as follows to ACL
bits for the *owner* of a mailbox and for the "anyone" identifier (in the
ACL):

On a mailbox that can contain messages:
  read: lr
  write: wite

(I'm not sure how to tie 's' -- maybe Mark can answer that).

On a mailbox that can contain mailboxes:
  read: l
  write: cx

"Dual-use" mailboxes get the union of the applicable above sets of bits.

Identifiers in the ACL that correspond to entities other than the
owner and 'anyone' are not advertised through the permissions extension.

Note that in a ACL+PERMISSIONS system, the rights advertised through the
PERMISSIONS extension are exactly the rights that match the owner's identifier
and the "anyone" identifier.  Negative rights are not advertised through,
the PERMISSIONS system.  When resolving actual rights, the ACL must be fully
calculated (i.e. the PERMISSIONS interface is just an alternate way to get
to *some* of the functionality of ACL).

Note also that this does not tie 'a' or 'p' to anything,
I would expect the PERMISSIONS extension to honor 'a', and I would expect
'p' to only be manipulatable through the ACL extension, though perhaps that
isn't quite the right thing.

If a server implements *only* PERMISSIONS and does not implement ACL, then it
should keep the semantics that would be provided by the ACL bits as
defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner).
However, in this case, the bits advertised through PERMISSIONS *are*
authoritative.

I think that this setup is significantly simpler than having to bend over
backwards to force ACLs onto unix filesystem semantics just to allow simple
folder sharing, and it still allows enterprise servers to continue to
support the flexibility provided by the ACL extension.

I've intentionally left some things open here: specifically interaction
with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire.
I have also left open the question of interpreting the ACL (rather, I left
it as it was in 2086).  The syntax question, at least, could be worked out when
a formal draft was issued.

I will note that this does not provide for groups to be used through the
PERMISSIONS mechanism.  However, it seems to me that the large demand
is "share folders globally", and this provides for that.

This would also provide a simple standard mapping for "read" and "write"
acls to mailboxes, which sees to also have been in demand.

Comments?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Nov 2003 19:08:04 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Bad chair - No blue sheet
Sender: [email-masked]

I have shirked one of my responsibilities: I forgot to get the blue 
sheet for the IMAPEXT meeting. :-(

I remember everyone there who said something. I know there were at 
least three people (and probably a couple more) that were in the room 
that I missed. Please add to this list if you can help me:

Mark Crispin
Cyrus Daboo
Lisa Dusseault
Randy Gellens
Larry Greenfield
Philip Guenther
Ted Hardie
John Klensin
Chris Newman
Rob Siemborski

Thanks.

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

Date: Tue, 11 Nov 2003 18:39:38 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE/ANNOTATEMORE issues
Sender: [email-masked]

Cyrus Daboo wrote:

> ANNOTATE issues for discussion on Wednesday:
>
> - No comments after last draft. Currently no open issues... Is it 
> ready for last call? 

Most likely.

> ANNOTATEMORE issues:
>
> - SETANNOTATION on multiple mailboxes - how to handle partial 
> failures. Some solutions:
>
>    * Fail entire annotation change on all mailboxes. Requires server 
> to rollback all changes across all mailboxes.
>    * Allow partial failure/success untagged response to indicate which 
> changes succeeded or failed, if some of them fail.
>    * Don't allow multi-mailbox SETANNOTATION. 

I think the first choice is non practical. The second is already 
suggested by ACL2.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Mon, 10 Nov 2003 10:56:49 -0600
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE/ANNOTATEMORE issues
Sender: [email-masked]

ANNOTATE issues for discussion on Wednesday:

- No comments after last draft. Currently no open issues... Is it ready for 
last call?

ANNOTATEMORE issues:

- SETANNOTATION on multiple mailboxes - how to handle partial failures. 
Some solutions:

    * Fail entire annotation change on all mailboxes. Requires server to 
rollback all changes across all mailboxes.
    * Allow partial failure/success untagged response to indicate which 
changes succeeded or failed, if some of them fail.
    * Don't allow multi-mailbox SETANNOTATION.

-- 
Cyrus Daboo

Date: Wed, 5 Nov 2003 09:28:48 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Abhijit Menon-Sen <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

On Wed, 5 Nov 2003, Arnt Gulbrandsen wrote:
> No. The argument goes: If you can't prevent <whatever> from being in
> IMAP anyway, cave in and at least avoid having it in two places.

But the ability to delete attachments is very different from composing new
messages or editing an existing message.  Some implementations *may*
accomplish this by similar means, but that is implementation rather than
concept.

Furthermore, if compose is placed in IMAP, then composition is stuck with
using IMAP forever.  POP and NNTP clients will now have to have IMAP
client code in order to do compose with those protocols (you could add
compose to POP and NNTP.  Now you have compose in three places).

Time and time again, I hear "IMAP is a lousy design, IMAP is too weak to
do anything useful, IMAP is going to have to be completely redesigned and
replaced from the ground up."  Why then do you want to create long-term
dependencies upon IMAP?

The superior solution is to have compose as a separate service,
independent of any particular message access protocol, and thus equally
usable with all message access mechanisms.  This requires mechanisms and
profiles, such as URLAUTH, to allow the compose service access to message
data in IMAP, POP, NNTP, and future protocols.

If building monoliths is so good, what is the point of having multiple
protocols in the IETF suite?  Why not have a single protocol for
everything, such as the videotex systems of the 1970s?

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: [email-masked], Abhijit Menon-Sen <[email-masked]>
Date: Wed, 5 Nov 2003 17:21:50 +0100
Sender: [email-masked]

Mark Crispin writes:
> On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote:
>>  If we're going down that road, perhaps we should consider 
>>  implementing a more flexible mechanism $B`(B la URLAUTH/COMPOSE, 
>>  which allows more than just removing

(why this corruption?)

>>   attachments. It seems inevitable that users will want to recompose 
>>  messages in other ways, and I'm worried about having several 
>>  mechanisms doing vaguely the same (set of) things.
>
> This doesn't make sense to me. The extreme form of that argument leads 
> to the conclusion that SMTP should be in IMAP because you can delete 
> and expunge messages in IMAP.

No. The argument goes: If you can't prevent <whatever> from being in 
IMAP anyway, cave in and at least avoid having it in two places.

"Unavoidable" is very different from "good".

> It seems to me that people who ask for this really don't want IMAP; 
> they want Exchange.

That could be.

--Arnt

Date: Wed, 5 Nov 2003 08:02:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
cc: [email-masked]
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote:
> If we're going down that road, perhaps we should consider implementing
> a more flexible mechanism $B`(B la URLAUTH/COMPOSE, which allows more than
> just removing attachments. It seems inevitable that users will want to
> recompose messages in other ways, and I'm worried about having several
> mechanisms doing vaguely the same (set of) things.

This doesn't make sense to me.  The extreme form of that argument leads to
the conclusion that SMTP should be in IMAP because you can delete and
expunge messages in IMAP.

If you want to *edit* a message (something which I personally believe is
morally wrong -- it is taking a real message from someone else and
creating a forgery), then some form of COMPOSE mechanism is necessary.

Editing is different from a mechanism that merely removes some attachments
but leaves the message itself intact.

Nor does having a COMPOSE functionality necessitate it being in IMAP.
COMPOSE takes IMAP far afield from its mission of message access.  We have
numerous examples of server implementations that don't get the in-mission
tasks of IMAP right.  How then can anyone believe that further bloating
IMAP with extraneous tasks will result in better-working servers?

It seems to me that people who ask for this really don't want IMAP; they
want Exchange.  IMAP is designed to be small tool among a set of small
tools, each of which does its own job well; Exchange is designed to be a
monolith that does everything.  I hope that people aren't still being
mislead by the long-standing myth that "TCP connections are expensive."

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'Pete Maclean'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Selective removal of attachments in a message
Date: Wed, 5 Nov 2003 19:15:26 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Mark, Pete,

	Thank you for your comments.

	Yes, I have totally agree with your comments and would
	work on the solution part and would send the completed
	draft.

> remove data anywhere. This is a guaranteed (and useful) 
> property of IMAP, but it does preclude the more 
> straightforward scheme of "selective removal of attachments" 
> that Madan Ganesh suggested.
	
	Pls help me in understanding this statement. As I described
	in the draft-draft version, I've been working on how we would
	remove the attachment and have not disclosed how IMAP could
	achieve this.

	As you suggested, the REMOVE should do an atomic operation :
		Copy the message with modification to the end of the
mailbox
				+
		Expunge the original message.

	Please let me know your comments.

	Thanks and Regards,
	MG

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Crispin
> Sent: Wednesday, November 05, 2003 6:25 AM
> To: Pete Maclean
> Cc: Madan Ganesh Velayudham; 'IMAP Extensions WG'
> Subject: Re: Selective removal of attachments in a message
> 
> 
> 
> On Tue, 4 Nov 2003, Pete Maclean wrote:
> > >It would be a nice feature to have; however, it violates 
> the IMAP UID 
> > >model which guarantees that a UID refers to an immutable object.
> > Why does it have to violate the model?  Surely if the spec 
> says that 
> > on processing a REMOVE, the server MUST assign the message 
> a new UID 
> > then it would be okay.  The old UID would be expunged and 
> the new UID 
> > would be reported in the REMOVE response.
> 
> I'm not sure if we're loudly agreeing or not.  Let's see if 
> this explanation helps:
> 
> A message on the server can not be altered.  The UID refers 
> to an immutable object.
> 
> UIDs are strictly ascending.  Thus for any pair of messages 
> m1 and m2, one of the following relations is true:
> 	(UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2))
> or
> 	(UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2))
> 
> Consequently, the only way to have the functionality of 
> "remove an attachment from a message" is to append a new copy 
> of the message to the mailbox (with the attachment deleted) 
> and possibly also delete+expunge the original copy.  The new 
> copy will have a new UID *and* a new relative position (using 
> sequence numbers) in the mailbox.
> 
> We are talking about a possible functionality by which the 
> current multistep process could be atomic.  I agree that this 
> would be desirable, and support it; but I also pointed out 
> some pitfalls that need to be addressed.
> 
> > Is the problem that other clients would not be able to 
> relate the new 
> > version of the message to the old?
> 
> This isn't the issue.  Any relationship will have to be with 
> whatever mechanisms are already being used, e.g. Message-ID.
> 
> What is the issue is that data in the middle of the mailbox 
> can not be altered or added.  You can add data at the end, or 
> remove data anywhere. This is a guaranteed (and useful) 
> property of IMAP, but it does preclude the more 
> straightforward scheme of "selective removal of attachments" 
> that Madan Ganesh suggested.
> 
> So we need a little bit of creativity to do something that 
> IMAP will tolerate.
> 
> -- Mark --
> 
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 5 Nov 2003 10:46:06 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

At 2003-11-04 14:55:07 -0800, [email-masked] wrote:
>
> > Then we're back to the 'copy without attachments' approach...
> 
> Yes.  I think that such an extension is potentially a very good idea,
> and I would support it.

If we're going down that road, perhaps we should consider implementing
a more flexible mechanism à la URLAUTH/COMPOSE, which allows more than
just removing attachments. It seems inevitable that users will want to
recompose messages in other ways, and I'm worried about having several
mechanisms doing vaguely the same (set of) things.

I supported hitherto the idea of having a separate submission server,
but if an IMAP extension is inevitable, I'd rather have just one that
addresses all of these requirements.

-- ams

Date: Tue, 04 Nov 2003 21:17:21 -0500
To: Mark Crispin <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: Madan Ganesh Velayudham <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

At 04:54 PM 11/4/2003 -0800, Mark Crispin wrote:

>On Tue, 4 Nov 2003, Pete Maclean wrote:
> > >It would be a nice feature to have; however, it violates the IMAP UID
> > >model which guarantees that a UID refers to an immutable object.
> > Why does it have to violate the model?  Surely if the spec says that on
> > processing a REMOVE, the server MUST assign the message a new UID then it
> > would be okay.  The old UID would be expunged and the new UID would be
> > reported in the REMOVE response.
>
>I'm not sure if we're loudly agreeing or not.

I think we are agreeing.  But I should perhaps have paid more attention to 
subsequent messages in this thread before responding since, I realize now, 
that what I am suggesting is equivalent to a COPY-with-modifications 
(restricted to the same mailbox) followed by an expunge -- but all done as 
an atomic operation.

I like the idea of having this as an atomic operation.  I think it is 
easier to express it in terms of REMOVE rather than 
COPY-with-modifications.  However it might be effectively redundant in 
light of the proposed COMPOSE.  And, yes, I understand your points about 
possible difficulties in implementation (as for a MOVE) although I have 
little experience with quota issues in particular.

Pete Maclean

Date: Tue, 4 Nov 2003 16:54:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Madan Ganesh Velayudham <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Pete Maclean wrote:
> >It would be a nice feature to have; however, it violates the IMAP UID
> >model which guarantees that a UID refers to an immutable object.
> Why does it have to violate the model?  Surely if the spec says that on
> processing a REMOVE, the server MUST assign the message a new UID then it
> would be okay.  The old UID would be expunged and the new UID would be
> reported in the REMOVE response.

I'm not sure if we're loudly agreeing or not.  Let's see if this
explanation helps:

A message on the server can not be altered.  The UID refers to an
immutable object.

UIDs are strictly ascending.  Thus for any pair of messages m1 and m2,
one of the following relations is true:
	(UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2))
or
	(UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2))

Consequently, the only way to have the functionality of "remove an
attachment from a message" is to append a new copy of the message to the
mailbox (with the attachment deleted) and possibly also delete+expunge the
original copy.  The new copy will have a new UID *and* a new relative
position (using sequence numbers) in the mailbox.

We are talking about a possible functionality by which the current
multistep process could be atomic.  I agree that this would be desirable,
and support it; but I also pointed out some pitfalls that need to be
addressed.

> Is the problem that other clients would not be able to relate the new
> version of the message to the old?

This isn't the issue.  Any relationship will have to be with whatever
mechanisms are already being used, e.g. Message-ID.

What is the issue is that data in the middle of the mailbox can not be
altered or added.  You can add data at the end, or remove data anywhere.
This is a guaranteed (and useful) property of IMAP, but it does preclude
the more straightforward scheme of "selective removal of attachments" that
Madan Ganesh suggested.

So we need a little bit of creativity to do something that IMAP will
tolerate.

-- Mark --

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

Date: Tue, 04 Nov 2003 19:21:06 -0500
To: Mark Crispin <[email-masked]>, Madan Ganesh Velayudham <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

>It would be a nice feature to have; however, it violates the IMAP UID
>model which guarantees that a UID refers to an immutable object.  It isn't
>going to happen

Why does it have to violate the model?  Surely if the spec says that on 
processing a REMOVE, the server MUST assign the message a new UID then it 
would be okay.  The old UID would be expunged and the new UID would be 
reported in the REMOVE response.

Is the problem that other clients would not be able to relate the new 
version of the message to the old?  This might be undesirable but consider 
that, for any mailstore for which access is available by alternate means 
(in addition to IMAP), such an event might well be possible anyway.

Pete Maclean

Date: Tue, 4 Nov 2003 15:20:04 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> can
> 'copy-without-attachments' be implemented as an atomic operation that will
> not be impacted by quota limits?

Certainly it "can".  It depends upon how it is defined.

This sounds like a case has finally been made for a MOVE command; that is,
it would not just be a COPY+DELETE, it would also include an expunge
single message.

The problem that I see here is that it may be difficult for an
implementation to do the operation safely.  Suppose it has to do the
EXPUNGE step before writing the new message, and then finds that it can't
actually do the write.  It now is unable to undo the operation, and the
message has been lost.

What highlights this problem is that the stated purpose is to get around
quota problems.  Some operating systems are so fascistic in enforcing
quotas that they won't let you even do a write() on top of existing data,
which in turn renders EXPUNGE in a flat file format impossible.

I think that along with the specification for this extension some
implementation recommendations are needed.  Even servers which control
their own quota enforcement (and thus can waive it) still have the problem
with a disk full condition.

Given that the server is unable to make the copy without first expunging
the original (quotas beyond its control, disk full), how should it
proceed?

If the answer is "punt", then this extension can't be used to fix a "quota
exceeded"/"disk full" condition.

If the answer is "try and hope for the best", then this extension has a
risk of losing the message.

-- Mark --

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

Date: Tue, 4 Nov 2003 14:09:29 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> 3) A client that has cached the MIME structure but not the content:
> provided the client does not rely on the bodystructure size indicators (and
> of course it should not)
  ^^^^^^^^^^^^^^^^^^^^^^^

I strongly disagree.

If you can't rely upon bodystructure size indicators then there is no
reasonable way to implement partial fetching.

Your proposal also breaks RFC822.SIZE.

-- Mark --

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

Date: Tue, 4 Nov 2003 14:55:07 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> OK, good point. Then we're back to the 'copy without attachments'
> approach...

Yes.  I think that such an extension is potentially a very good idea, and
I would support it.

-- Mark --

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

Date: Tue, 04 Nov 2003 18:01:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 02:55:07 PM -0800 Mark Crispin 
<[email-masked]> wrote:

| On Tue, 4 Nov 2003, Cyrus Daboo wrote:
|> OK, good point. Then we're back to the 'copy without attachments'
|> approach...
|
| Yes.  I think that such an extension is potentially a very good idea, and
| I would support it.

The question is can we do this in a way that is 'quota' friendly. 
Specifically, users most often need the 'remove attachments' command when 
they run over quota (or close to the limit) and need to get back down. The 
'copy-with-attachments/delete/expunge-original' isn't going to work in that 
case because quota will not allow the copy (this is the same as the 
'copy-to-trash' problem that often comes up). So, can 
'copy-without-attachments' be implemented as an atomic operation that will 
not be impacted by quota limits?

-- 
Cyrus Daboo

Date: Tue, 04 Nov 2003 17:46:22 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 02:09:29 PM -0800 Mark Crispin 
<[email-masked]> wrote:

|> 3) A client that has cached the MIME structure but not the content:
|> provided the client does not rely on the bodystructure size indicators
|> (and of course it should not)
|   ^^^^^^^^^^^^^^^^^^^^^^^
|
| I strongly disagree.
|
| If you can't rely upon bodystructure size indicators then there is no
| reasonable way to implement partial fetching.
|
| Your proposal also breaks RFC822.SIZE.

OK, good point. Then we're back to the 'copy without attachments' 
approach...

-- 
Cyrus Daboo

Date: Tue, 04 Nov 2003 14:22:52 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 11:00:46 AM -0800 Mark Crispin 
<[email-masked]> wrote:

| It would be a nice feature to have; however, it violates the IMAP UID
| model which guarantees that a UID refers to an immutable object.  It isn't
| going to happen
|
| A way to work around the problem (and something that some people would
| probably like) would be a "copy message without listed attachments"
| command.  So, while you can't delete the attachment from the original
| message, you can make a copy of the message without the attachment and
| delete the original message.  The benefit of the new command would be that
| the client wouldn't have to download the message just to append it back;
| currently that's the only way to do "delete attachment".

That sounds a little like the 'compose on the server' extension for 
lemonade!

Actually, there is one potential way to get around the immutable message 
situation without caching problems with disconnected clients. Rather than 
delete the actual MIME part, the delete command would instead remove the 
MIME part content, but leave the MIME structure intact - i.e. fetching the 
MIME body returns nothing. Removal would also change the 
content-disposition on the removed parts to a new type of 'removed' with 
some ancillary parameters to indicate when it was removed etc.

How would this affect clients:

1) A client that has never seen the message before will not be affected, 
except for the fact that the user will see empty parts. The 
content-disposition can be used to show that the part content was deleted 
at some point in the past.

2) A client that has cached the entire message (mime structure and content) 
will not be affected as it will retrieve the mime content from its local 
cache.

3) A client that has cached the MIME structure but not the content: 
provided the client does not rely on the bodystructure size indicators (and 
of course it should not) there should be no problem about the fact that the 
client gets back zero bytes for the MIME body. The user may be surprised by 
this (as in situation 1) and it may be hard to determine exactly what 
happened as the cached bodystructure won't include the new 
content-disposition: removed indicator.

I think this is as close as you can get to an in-place attachment removal 
mechanism without causing caching problems for clients - however, the 
unexpected case in situation (3) may not be tolerable. Perhaps there are 
other issues I've not considered that would make this inappropriate?

-- 
Cyrus Daboo

Date: Tue, 4 Nov 2003 11:00:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

It would be a nice feature to have; however, it violates the IMAP UID
model which guarantees that a UID refers to an immutable object.  It isn't
going to happen

A way to work around the problem (and something that some people would
probably like) would be a "copy message without listed attachments"
command.  So, while you can't delete the attachment from the original
message, you can make a copy of the message without the attachment and
delete the original message.  The benefit of the new command would be that
the client wouldn't have to download the message just to append it back;
currently that's the only way to do "delete attachment".

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'IMAP Extensions WG'" <[email-masked]>
Cc: "'Madan Ganesh Velayudham'" <[email-masked]>
Subject: Selective removal of attachments in a message
Date: Wed, 5 Nov 2003 00:24:39 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C3A333.336AE950
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

	Please share your thoughts on the attached document.

	Sincerely,
	MG

	**************************
	Madan Ganesh Velayudham
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

------=_NextPart_000_0007_01C3A333.336AE950
Content-Type: text/plain;
	name="madanganeshv-remove-attachment-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="madanganeshv-remove-attachment-00.txt"

	REMOVE: Selective removal of attachments from a Message 
	=========================================================

Abstract

	Clients could want to remove attachments selectively from 
	a message in the mailbox. Currently there is no mechanism 
	by which a IMAP client can achieve this.

Overview :

	[RFC 3501] defines DELETE command to delete a mailbox and 
	store \Deleted + EXPUNGE sequence to permanently delete a
	message in a mailbox.

	There is no way by which a client can selectively delete/
	remove attachments or message parts from a message in a mailbox.
	
	As decribed in the Section 6.4.5 of [RFC 3501], every message
	has at least one part number.  Non-[MIME-IMB] messages, and non
	-multipart messages with no encapsulated message, only have a 
	part 1.

        Multipart messages are assigned consecutive part numbers, as
        they occur in the message.  If a particular part is of type
        message or multipart, its parts MUST be indicated by a period
        followed by the part number within that nested multipart part.

        A part of type MESSAGE/RFC822 also has nested part numbers,
        referring to parts of the MESSAGE part's body.              
        
        Clients can use REMOVE command to remove part(s) of message(s)
        in a mailbox.

CAPABILITY identification

	IMAP4 servers that support this extension MUST include an REMOVE
	capability response in teh response list to the CAPABILITY command.

REMOVE Command
	
  Arguments: sequence set
   	     message data item names
	
  Responses: untagged responses: REMOVE
	
  Result:    OK - Remove completed
  	     NO - Remove error
  	     BAD - Command Unknown
		   
  The REMOVE command removes part associated with a message in the mailbox.
    
Return codes and other issues
  
  	WORK IN PROGRESS
  
Security considerations
  
  	WORK IN PROGRESS
        
Author          
  
  Madan Ganesh Velayudham
  Hewlett-Packard
  
  [email-masked]
  +91-80-205-3108

------=_NextPart_000_0007_01C3A333.336AE950--

Date: Tue, 4 Nov 2003 08:43:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

On Tue, 4 Nov 2003, Pete Resnick wrote:
> >Probably URLAUTH needs at least a glance.
> I don't necessarily object to our discussing it (if we've got time),
> but aren't all of the "usual suspects" going to be in LEMONADE anyway?

Agreed, but an "IMAPEXT point of view" would be useful.

-- Mark --

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

Date: Tue, 4 Nov 2003 10:11:01 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Proposed agenda?
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/3/03 at 11:04 PM -0800, Mark Crispin wrote:

>Probably URLAUTH needs at least a glance.

I don't necessarily object to our discussing it (if we've got time), 
but aren't all of the "usual suspects" going to be in LEMONADE anyway?

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

Date: Mon, 3 Nov 2003 23:04:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

On Mon, 3 Nov 2003, Pete Resnick wrote:
> I'd very much like to hear from Chris Newman and Cyrus and/or Randy
> about what we will be discussing re: their documents. Anyone else
> have stuff to talk about?

Probably URLAUTH needs at least a glance.

-- Mark --

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

Date: Mon, 3 Nov 2003 21:06:46 -0600
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Proposed agenda?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/1/03 at 2:40 PM +0000, Alexey Melnikov wrote:

>I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting.

I'd very much like to hear from Chris Newman and Cyrus and/or Randy 
about what we will be discussing re: their documents. Anyone else 
have stuff to talk about?

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

Date: Sat, 01 Nov 2003 15:49:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |
> | I still haven't heard any agenda proposals for Minneapolis IMAPEXT
> | meeting.
> | As I am not attending this meeting, I would like to know in advance 
> what
> | I am going to miss.
> |
> | Is there any point for doing a draft revision of ACL2 for people to
> | discuss in Minneapolis?
> | (I am a bit busy at work right now, so this is a selfish question. 
> But I
> | will produce something
> | if people think it is necessary/beneficial to discuss the document in
> | Minneapolis)
>
> How about the current document authors summarize the outstanding 
> issues with their docs on the list early next week and that can form 
> the basis for the agenda (or perhaps we can even resolve the issues on 
> the list before the meeting).

Ok.

CONDSTORE: I've sent private email to Application Area ADs with some 
clarifications. I got no response yet. Hopefully the answer would be 
that I need to do a minor revision to the document and no Last Call 
would be required.

ACL2: I've done nothing since August. I was reading various discussion 
threads, but I have yet to summarize required changes.

No changes to Keywords so far. I mostly agree with Mark on silly states 
and complicated dependencies, but I personally would like to keep 
certain keywords that he and Lyndon proposed to remove.

Revision of "disconnected clients" will come shortly after the 
Minneapolis meeting.

I've requested Ned/Ted to Last Call UNSELECT.

I've done almost nothing on QUOTA plus (draft-cridland-imap-quota-00.txt)

Alexey

Date: Sat, 01 Nov 2003 10:19:03 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

Hi Alexey,

--On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov 
<[email-masked]> wrote:

|
| I still haven't heard any agenda proposals for Minneapolis IMAPEXT
| meeting.
| As I am not attending this meeting, I would like to know in advance what
| I am going to miss.
|
| Is there any point for doing a draft revision of ACL2 for people to
| discuss in Minneapolis?
| (I am a bit busy at work right now, so this is a selfish question. But I
| will produce something
| if people think it is necessary/beneficial to discuss the document in
| Minneapolis)

How about the current document authors summarise the outstanding issues 
with their docs on the list early next week and that can form the basis for 
the agenda (or perhaps we can even resolve the issues on the list before 
the meeting).

-- 
Cyrus Daboo

Date: Sat, 01 Nov 2003 14:40:31 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Proposed agenda?
Sender: [email-masked]

I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting.
As I am not attending this meeting, I would like to know in advance what 
I am going to miss.

Is there any point for doing a draft revision of ACL2 for people to 
discuss in Minneapolis?
(I am a bit busy at work right now, so this is a selfish question. But I 
will produce something
if people think it is necessary/beneficial to discuss the document in 
Minneapolis)

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 13:27:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked], Lyndon Nerenberg <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

Pete Resnick wrote:

> On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote:
>
>> If serious discussions are going to take place on the jabber list, is 
>> it possible to have some summary of those posted to the email list
>
> Absolutely, though my feeling is that serious discussions should *not* 
> take place in jabber at this point. Jabber might be a nice way, if 
> someone happens to be around, to ask a quick "Hey, what's the status 
> of my draft?" or "I don't understand a piece of this draft. Can 
> someone explain what I'm missing, or should I bring this to the author 
> as a problem?" kind of question. I expect serious issue discussions to 
> always be on the list.

IMHO, Jabber is a very useful tool for real time communication with 
people who are unable to attend. And, IMHO, partial feedback is better 
than no feedback.
Of course it doesn't replace mailing list discussions.

Selecting a good scribe is a non trivial task (and makes a big 
difference). Maybe we should bribe well- known-good-scribes (e.g. 
Marshall Rose) ;-)?

Alexey

Date: Mon, 24 Nov 2003 10:35:12 -0800 (PST)
From: [email-masked]
Subject: AD review comments on draft-ietf-imapext-sort-13.txt
To: [email-masked]
Sender: [email-masked]

This documents defines two threading algorithms, ORDEREDSUBJECT and REFERENCES,
and the IANA considerations section makes it sound like there's a registry for
threading algorithms with these as the two initial entries. However, this
document doesn't actually define such a registry. I see two possibilities here:
There are only two threading algorithms, end of story, no registry needed and
hence the text about this in the IANA considerations section needs to be
removed (unlikely), or else this document creates a new registry for threading
algorithms with these two as the initial entries. If it is the latter there
needs to be text added to define the registry and explain what the registration
procedures are (RFC required, first come first serve, etc.). 

In the "Sent Date" section, the procedure implied by "adjusted by time zone"
needs to be spelled out in a little more detail lest we end up with some
"creative" interpretations and corresponding implementations. It might also
make sense to discuss how to handle a date field with an invalid time zone
specification.

In the discussion of the charset argument for SORT and THREAD, reference is
made to the charset argument to SEARCH defined in the base specification, but
this document doesn't actually come out and specify that the semantics of SORT
and THREAD's charset argument are the same as that for SEARCH's. I suggest
adding a sentence along the lines of "The charset argument indicates the
[CHARSET] of the strings that appear in the {sort|thread} criteria." to the
relevant sections. The [CHARSET] reference would also need to be added to the
normative references.

The section containing the ABNF needs to state that it employs ABNF productions
defined in RFC 3501.

In the ABNF, change "; CHARSET argument to MUST be registered with IANA" to
read "; CHARSET values MUST be registered with IANA"

The RFC Editor views abstracts as essentially separate from the document
propoer. As such, it is usually necessary to have both an Abstract describing
the document as a whole very tersely and a separate introduction to the
specification that describes its purpose in a bit more detail.

The paragraph on MUST/SHOULD/MAY/etc. conventions needs to be moved to a
section of its own separate from the abstract.

The paragraph discussing capability announcment of the SORT and THREAD
extensions also needs to be moved to a separate section.

This document doesn't contain either the copyright or the IPR
boilerplate required by RFC 2026. 

The section numbering in this document is, well, strange. Most sections aren't
numbered, but then near the end up pops a section 12 and appendix A. I
understand the desire to want to use section numbers to align the command and
response material with RFC 3501, but I don't think this obviates the need for
the rest of the document to have sensible section numbers. Here's an alternate
suggestion: For the sections intended to be "inserted" into RFFC 3501, preface
the section numbers with "BASE." or something similar. Then number the various
other sections  of this document normally. 

That's it!

				Ned

Date: Sat, 15 Nov 2003 10:51:20 -0600
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

Hi Rob,

--On Friday, November 14, 2003 18:41 -0500 Rob Siemborski 
<[email-masked]> wrote:

| Comments?

As a general comment I would support a split to two ACL mechanisms: a 
simple one and a complex one (the later being based on the existing ACL). I 
think ACL2 has become too unwieldy in trying to support arbitrary ACL 
models and will ultimately prove to be a huge hurdle to implementation on 
the client (which is the end that potentially has to support the multitude 
of server models that can exist). It was pointed out in the meeting that 
WebDAV seems to suffer from that problem - the server's model is over 
generalized and its hard for a client to get all the possible options right 
- interop is poor.

So I think Rob is on the right track - we need an ACL+ to update the 
existing ACL spec. Then a simple Read-Only/Read-Write ACL model extension. 
The two need to co-exist, but a server may support only one, though I think 
we should recommend an ACL+ server also support PERMISSIONS.

Of course this does mean writing off the current ACL2 spec (though much of 
the work for ACL+ has been done in ACL2). There are also other extensions 
that have a dependency on ACL and those would need to be held up until we 
can decide what to do (I'm primarily thinking about ANNOTATE here). That's 
probably not something Pete wants to hear - but I think we can get 
ACL+PERMISSIONS done quickly - and it would probably be faster than trying 
to resolve all the issues with ACL2's arbitrary models.

It also means effectively having two ACL extensions rather than one. The 
question is whether the IESG would push-back on that - we need to get input 
from the ADs on that matter before we can decide whether to go ahead with 
this. Clearly we would pitch this as a simplification of this work - 
cutting down an arbitrary ACL model implementation (with many possible 
models) to two fixed models, which should make implementations and security 
analysis etc much easier to accomplish.

-- 
Cyrus Daboo

Date: Fri, 14 Nov 2003 19:26:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

Hi Rob -

This is an interesting idea.  Give me some time to mull it over.  This may
be the way out!

-- Mark --

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

Date: Fri, 14 Nov 2003 18:41:14 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Yet another ACL Strawman
Sender: [email-masked]

After the IMAPext meeting I spoke with some people and got to thinking if
there was a way we could come up with a way to do IMAP sharing that will
satisfy both the enterprise people who need detailed ACL support, and those
who feel the need to implement permissions with limited backend support
(e.g. UNIX file permissions).  Ideally, such a mechanism would be simple to
implement and not have complexity problems getting past the IESG.

I'd like to propose the following as a strawman INSTEAD of the
current ACL2 draft (or whatever ACL2 became after the last round of
comments):

Create an ACL+ capability that does the following:

  * Can only be advertised if ACL is advertised
  * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE)
bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2)

There may be other changes from ACL2 that I missed here, but the general
goal is "do the minimum required to fix ACL".  This may imply changing how
the namespace of identifiers are treated as well (e.g. user=foo,
group=bar), but I'd really like to keep the changes as minimal as possible
here if we can.

Create a new PERMISSIONS capability that works along the lines of the
following:

  * Define four bits you can set on a mailbox: owner read/write and
anyone read/write.  Have a command other than the ACL manipulation
commands that can manipulate/report these.

If a server advertises *both* PERMISSIONS and ACL, then it must also
advertise ACL+.  Also, the PERMISSIONS bits are tied as follows to ACL
bits for the *owner* of a mailbox and for the "anyone" identifier (in the
ACL):

On a mailbox that can contain messages:
  read: lr
  write: wite

(I'm not sure how to tie 's' -- maybe Mark can answer that).

On a mailbox that can contain mailboxes:
  read: l
  write: cx

"Dual-use" mailboxes get the union of the applicable above sets of bits.

Identifiers in the ACL that correspond to entities other than the
owner and 'anyone' are not advertised through the permissions extension.

Note that in a ACL+PERMISSIONS system, the rights advertised through the
PERMISSIONS extension are exactly the rights that match the owner's identifier
and the "anyone" identifier.  Negative rights are not advertised through,
the PERMISSIONS system.  When resolving actual rights, the ACL must be fully
calculated (i.e. the PERMISSIONS interface is just an alternate way to get
to *some* of the functionality of ACL).

Note also that this does not tie 'a' or 'p' to anything,
I would expect the PERMISSIONS extension to honor 'a', and I would expect
'p' to only be manipulatable through the ACL extension, though perhaps that
isn't quite the right thing.

If a server implements *only* PERMISSIONS and does not implement ACL, then it
should keep the semantics that would be provided by the ACL bits as
defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner).
However, in this case, the bits advertised through PERMISSIONS *are*
authoritative.

I think that this setup is significantly simpler than having to bend over
backwards to force ACLs onto unix filesystem semantics just to allow simple
folder sharing, and it still allows enterprise servers to continue to
support the flexibility provided by the ACL extension.

I've intentionally left some things open here: specifically interaction
with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire.
I have also left open the question of interpreting the ACL (rather, I left
it as it was in 2086).  The syntax question, at least, could be worked out when
a formal draft was issued.

I will note that this does not provide for groups to be used through the
PERMISSIONS mechanism.  However, it seems to me that the large demand
is "share folders globally", and this provides for that.

This would also provide a simple standard mapping for "read" and "write"
acls to mailboxes, which sees to also have been in demand.

Comments?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Nov 2003 19:08:04 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Bad chair - No blue sheet
Sender: [email-masked]

I have shirked one of my responsibilities: I forgot to get the blue 
sheet for the IMAPEXT meeting. :-(

I remember everyone there who said something. I know there were at 
least three people (and probably a couple more) that were in the room 
that I missed. Please add to this list if you can help me:

Mark Crispin
Cyrus Daboo
Lisa Dusseault
Randy Gellens
Larry Greenfield
Philip Guenther
Ted Hardie
John Klensin
Chris Newman
Rob Siemborski

Thanks.

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

Date: Tue, 11 Nov 2003 18:39:38 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE/ANNOTATEMORE issues
Sender: [email-masked]

Cyrus Daboo wrote:

> ANNOTATE issues for discussion on Wednesday:
>
> - No comments after last draft. Currently no open issues... Is it 
> ready for last call? 

Most likely.

> ANNOTATEMORE issues:
>
> - SETANNOTATION on multiple mailboxes - how to handle partial 
> failures. Some solutions:
>
>    * Fail entire annotation change on all mailboxes. Requires server 
> to rollback all changes across all mailboxes.
>    * Allow partial failure/success untagged response to indicate which 
> changes succeeded or failed, if some of them fail.
>    * Don't allow multi-mailbox SETANNOTATION. 

I think the first choice is non practical. The second is already 
suggested by ACL2.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Mon, 10 Nov 2003 10:56:49 -0600
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE/ANNOTATEMORE issues
Sender: [email-masked]

ANNOTATE issues for discussion on Wednesday:

- No comments after last draft. Currently no open issues... Is it ready for 
last call?

ANNOTATEMORE issues:

- SETANNOTATION on multiple mailboxes - how to handle partial failures. 
Some solutions:

    * Fail entire annotation change on all mailboxes. Requires server to 
rollback all changes across all mailboxes.
    * Allow partial failure/success untagged response to indicate which 
changes succeeded or failed, if some of them fail.
    * Don't allow multi-mailbox SETANNOTATION.

-- 
Cyrus Daboo

Date: Wed, 5 Nov 2003 09:28:48 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Abhijit Menon-Sen <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

On Wed, 5 Nov 2003, Arnt Gulbrandsen wrote:
> No. The argument goes: If you can't prevent <whatever> from being in
> IMAP anyway, cave in and at least avoid having it in two places.

But the ability to delete attachments is very different from composing new
messages or editing an existing message.  Some implementations *may*
accomplish this by similar means, but that is implementation rather than
concept.

Furthermore, if compose is placed in IMAP, then composition is stuck with
using IMAP forever.  POP and NNTP clients will now have to have IMAP
client code in order to do compose with those protocols (you could add
compose to POP and NNTP.  Now you have compose in three places).

Time and time again, I hear "IMAP is a lousy design, IMAP is too weak to
do anything useful, IMAP is going to have to be completely redesigned and
replaced from the ground up."  Why then do you want to create long-term
dependencies upon IMAP?

The superior solution is to have compose as a separate service,
independent of any particular message access protocol, and thus equally
usable with all message access mechanisms.  This requires mechanisms and
profiles, such as URLAUTH, to allow the compose service access to message
data in IMAP, POP, NNTP, and future protocols.

If building monoliths is so good, what is the point of having multiple
protocols in the IETF suite?  Why not have a single protocol for
everything, such as the videotex systems of the 1970s?

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: [email-masked], Abhijit Menon-Sen <[email-masked]>
Date: Wed, 5 Nov 2003 17:21:50 +0100
Sender: [email-masked]

Mark Crispin writes:
> On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote:
>>  If we're going down that road, perhaps we should consider 
>>  implementing a more flexible mechanism $B`(B la URLAUTH/COMPOSE, 
>>  which allows more than just removing

(why this corruption?)

>>   attachments. It seems inevitable that users will want to recompose 
>>  messages in other ways, and I'm worried about having several 
>>  mechanisms doing vaguely the same (set of) things.
>
> This doesn't make sense to me. The extreme form of that argument leads 
> to the conclusion that SMTP should be in IMAP because you can delete 
> and expunge messages in IMAP.

No. The argument goes: If you can't prevent <whatever> from being in 
IMAP anyway, cave in and at least avoid having it in two places.

"Unavoidable" is very different from "good".

> It seems to me that people who ask for this really don't want IMAP; 
> they want Exchange.

That could be.

--Arnt

Date: Wed, 5 Nov 2003 08:02:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
cc: [email-masked]
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote:
> If we're going down that road, perhaps we should consider implementing
> a more flexible mechanism $B`(B la URLAUTH/COMPOSE, which allows more than
> just removing attachments. It seems inevitable that users will want to
> recompose messages in other ways, and I'm worried about having several
> mechanisms doing vaguely the same (set of) things.

This doesn't make sense to me.  The extreme form of that argument leads to
the conclusion that SMTP should be in IMAP because you can delete and
expunge messages in IMAP.

If you want to *edit* a message (something which I personally believe is
morally wrong -- it is taking a real message from someone else and
creating a forgery), then some form of COMPOSE mechanism is necessary.

Editing is different from a mechanism that merely removes some attachments
but leaves the message itself intact.

Nor does having a COMPOSE functionality necessitate it being in IMAP.
COMPOSE takes IMAP far afield from its mission of message access.  We have
numerous examples of server implementations that don't get the in-mission
tasks of IMAP right.  How then can anyone believe that further bloating
IMAP with extraneous tasks will result in better-working servers?

It seems to me that people who ask for this really don't want IMAP; they
want Exchange.  IMAP is designed to be small tool among a set of small
tools, each of which does its own job well; Exchange is designed to be a
monolith that does everything.  I hope that people aren't still being
mislead by the long-standing myth that "TCP connections are expensive."

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'Pete Maclean'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Selective removal of attachments in a message
Date: Wed, 5 Nov 2003 19:15:26 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

Hi Mark, Pete,

	Thank you for your comments.

	Yes, I have totally agree with your comments and would
	work on the solution part and would send the completed
	draft.

> remove data anywhere. This is a guaranteed (and useful) 
> property of IMAP, but it does preclude the more 
> straightforward scheme of "selective removal of attachments" 
> that Madan Ganesh suggested.
	
	Pls help me in understanding this statement. As I described
	in the draft-draft version, I've been working on how we would
	remove the attachment and have not disclosed how IMAP could
	achieve this.

	As you suggested, the REMOVE should do an atomic operation :
		Copy the message with modification to the end of the
mailbox
				+
		Expunge the original message.

	Please let me know your comments.

	Thanks and Regards,
	MG

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Crispin
> Sent: Wednesday, November 05, 2003 6:25 AM
> To: Pete Maclean
> Cc: Madan Ganesh Velayudham; 'IMAP Extensions WG'
> Subject: Re: Selective removal of attachments in a message
> 
> 
> 
> On Tue, 4 Nov 2003, Pete Maclean wrote:
> > >It would be a nice feature to have; however, it violates 
> the IMAP UID 
> > >model which guarantees that a UID refers to an immutable object.
> > Why does it have to violate the model?  Surely if the spec 
> says that 
> > on processing a REMOVE, the server MUST assign the message 
> a new UID 
> > then it would be okay.  The old UID would be expunged and 
> the new UID 
> > would be reported in the REMOVE response.
> 
> I'm not sure if we're loudly agreeing or not.  Let's see if 
> this explanation helps:
> 
> A message on the server can not be altered.  The UID refers 
> to an immutable object.
> 
> UIDs are strictly ascending.  Thus for any pair of messages 
> m1 and m2, one of the following relations is true:
> 	(UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2))
> or
> 	(UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2))
> 
> Consequently, the only way to have the functionality of 
> "remove an attachment from a message" is to append a new copy 
> of the message to the mailbox (with the attachment deleted) 
> and possibly also delete+expunge the original copy.  The new 
> copy will have a new UID *and* a new relative position (using 
> sequence numbers) in the mailbox.
> 
> We are talking about a possible functionality by which the 
> current multistep process could be atomic.  I agree that this 
> would be desirable, and support it; but I also pointed out 
> some pitfalls that need to be addressed.
> 
> > Is the problem that other clients would not be able to 
> relate the new 
> > version of the message to the old?
> 
> This isn't the issue.  Any relationship will have to be with 
> whatever mechanisms are already being used, e.g. Message-ID.
> 
> What is the issue is that data in the middle of the mailbox 
> can not be altered or added.  You can add data at the end, or 
> remove data anywhere. This is a guaranteed (and useful) 
> property of IMAP, but it does preclude the more 
> straightforward scheme of "selective removal of attachments" 
> that Madan Ganesh suggested.
> 
> So we need a little bit of creativity to do something that 
> IMAP will tolerate.
> 
> -- Mark --
> 
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 5 Nov 2003 10:46:06 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

At 2003-11-04 14:55:07 -0800, [email-masked] wrote:
>
> > Then we're back to the 'copy without attachments' approach...
> 
> Yes.  I think that such an extension is potentially a very good idea,
> and I would support it.

If we're going down that road, perhaps we should consider implementing
a more flexible mechanism à la URLAUTH/COMPOSE, which allows more than
just removing attachments. It seems inevitable that users will want to
recompose messages in other ways, and I'm worried about having several
mechanisms doing vaguely the same (set of) things.

I supported hitherto the idea of having a separate submission server,
but if an IMAP extension is inevitable, I'd rather have just one that
addresses all of these requirements.

-- ams

Date: Tue, 04 Nov 2003 21:17:21 -0500
To: Mark Crispin <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: Madan Ganesh Velayudham <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

At 04:54 PM 11/4/2003 -0800, Mark Crispin wrote:

>On Tue, 4 Nov 2003, Pete Maclean wrote:
> > >It would be a nice feature to have; however, it violates the IMAP UID
> > >model which guarantees that a UID refers to an immutable object.
> > Why does it have to violate the model?  Surely if the spec says that on
> > processing a REMOVE, the server MUST assign the message a new UID then it
> > would be okay.  The old UID would be expunged and the new UID would be
> > reported in the REMOVE response.
>
>I'm not sure if we're loudly agreeing or not.

I think we are agreeing.  But I should perhaps have paid more attention to 
subsequent messages in this thread before responding since, I realize now, 
that what I am suggesting is equivalent to a COPY-with-modifications 
(restricted to the same mailbox) followed by an expunge -- but all done as 
an atomic operation.

I like the idea of having this as an atomic operation.  I think it is 
easier to express it in terms of REMOVE rather than 
COPY-with-modifications.  However it might be effectively redundant in 
light of the proposed COMPOSE.  And, yes, I understand your points about 
possible difficulties in implementation (as for a MOVE) although I have 
little experience with quota issues in particular.

Pete Maclean

Date: Tue, 4 Nov 2003 16:54:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Madan Ganesh Velayudham <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Pete Maclean wrote:
> >It would be a nice feature to have; however, it violates the IMAP UID
> >model which guarantees that a UID refers to an immutable object.
> Why does it have to violate the model?  Surely if the spec says that on
> processing a REMOVE, the server MUST assign the message a new UID then it
> would be okay.  The old UID would be expunged and the new UID would be
> reported in the REMOVE response.

I'm not sure if we're loudly agreeing or not.  Let's see if this
explanation helps:

A message on the server can not be altered.  The UID refers to an
immutable object.

UIDs are strictly ascending.  Thus for any pair of messages m1 and m2,
one of the following relations is true:
	(UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2))
or
	(UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2))

Consequently, the only way to have the functionality of "remove an
attachment from a message" is to append a new copy of the message to the
mailbox (with the attachment deleted) and possibly also delete+expunge the
original copy.  The new copy will have a new UID *and* a new relative
position (using sequence numbers) in the mailbox.

We are talking about a possible functionality by which the current
multistep process could be atomic.  I agree that this would be desirable,
and support it; but I also pointed out some pitfalls that need to be
addressed.

> Is the problem that other clients would not be able to relate the new
> version of the message to the old?

This isn't the issue.  Any relationship will have to be with whatever
mechanisms are already being used, e.g. Message-ID.

What is the issue is that data in the middle of the mailbox can not be
altered or added.  You can add data at the end, or remove data anywhere.
This is a guaranteed (and useful) property of IMAP, but it does preclude
the more straightforward scheme of "selective removal of attachments" that
Madan Ganesh suggested.

So we need a little bit of creativity to do something that IMAP will
tolerate.

-- Mark --

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

Date: Tue, 04 Nov 2003 19:21:06 -0500
To: Mark Crispin <[email-masked]>, Madan Ganesh Velayudham <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Cc: "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

>It would be a nice feature to have; however, it violates the IMAP UID
>model which guarantees that a UID refers to an immutable object.  It isn't
>going to happen

Why does it have to violate the model?  Surely if the spec says that on 
processing a REMOVE, the server MUST assign the message a new UID then it 
would be okay.  The old UID would be expunged and the new UID would be 
reported in the REMOVE response.

Is the problem that other clients would not be able to relate the new 
version of the message to the old?  This might be undesirable but consider 
that, for any mailstore for which access is available by alternate means 
(in addition to IMAP), such an event might well be possible anyway.

Pete Maclean

Date: Tue, 4 Nov 2003 15:20:04 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> can
> 'copy-without-attachments' be implemented as an atomic operation that will
> not be impacted by quota limits?

Certainly it "can".  It depends upon how it is defined.

This sounds like a case has finally been made for a MOVE command; that is,
it would not just be a COPY+DELETE, it would also include an expunge
single message.

The problem that I see here is that it may be difficult for an
implementation to do the operation safely.  Suppose it has to do the
EXPUNGE step before writing the new message, and then finds that it can't
actually do the write.  It now is unable to undo the operation, and the
message has been lost.

What highlights this problem is that the stated purpose is to get around
quota problems.  Some operating systems are so fascistic in enforcing
quotas that they won't let you even do a write() on top of existing data,
which in turn renders EXPUNGE in a flat file format impossible.

I think that along with the specification for this extension some
implementation recommendations are needed.  Even servers which control
their own quota enforcement (and thus can waive it) still have the problem
with a disk full condition.

Given that the server is unable to make the copy without first expunging
the original (quotas beyond its control, disk full), how should it
proceed?

If the answer is "punt", then this extension can't be used to fix a "quota
exceeded"/"disk full" condition.

If the answer is "try and hope for the best", then this extension has a
risk of losing the message.

-- Mark --

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

Date: Tue, 4 Nov 2003 14:09:29 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> 3) A client that has cached the MIME structure but not the content:
> provided the client does not rely on the bodystructure size indicators (and
> of course it should not)
  ^^^^^^^^^^^^^^^^^^^^^^^

I strongly disagree.

If you can't rely upon bodystructure size indicators then there is no
reasonable way to implement partial fetching.

Your proposal also breaks RFC822.SIZE.

-- Mark --

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

Date: Tue, 4 Nov 2003 14:55:07 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 4 Nov 2003, Cyrus Daboo wrote:
> OK, good point. Then we're back to the 'copy without attachments'
> approach...

Yes.  I think that such an extension is potentially a very good idea, and
I would support it.

-- Mark --

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

Date: Tue, 04 Nov 2003 18:01:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 02:55:07 PM -0800 Mark Crispin 
<[email-masked]> wrote:

| On Tue, 4 Nov 2003, Cyrus Daboo wrote:
|> OK, good point. Then we're back to the 'copy without attachments'
|> approach...
|
| Yes.  I think that such an extension is potentially a very good idea, and
| I would support it.

The question is can we do this in a way that is 'quota' friendly. 
Specifically, users most often need the 'remove attachments' command when 
they run over quota (or close to the limit) and need to get back down. The 
'copy-with-attachments/delete/expunge-original' isn't going to work in that 
case because quota will not allow the copy (this is the same as the 
'copy-to-trash' problem that often comes up). So, can 
'copy-without-attachments' be implemented as an atomic operation that will 
not be impacted by quota limits?

-- 
Cyrus Daboo

Date: Tue, 04 Nov 2003 17:46:22 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 02:09:29 PM -0800 Mark Crispin 
<[email-masked]> wrote:

|> 3) A client that has cached the MIME structure but not the content:
|> provided the client does not rely on the bodystructure size indicators
|> (and of course it should not)
|   ^^^^^^^^^^^^^^^^^^^^^^^
|
| I strongly disagree.
|
| If you can't rely upon bodystructure size indicators then there is no
| reasonable way to implement partial fetching.
|
| Your proposal also breaks RFC822.SIZE.

OK, good point. Then we're back to the 'copy without attachments' 
approach...

-- 
Cyrus Daboo

Date: Tue, 04 Nov 2003 14:22:52 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 04, 2003 11:00:46 AM -0800 Mark Crispin 
<[email-masked]> wrote:

| It would be a nice feature to have; however, it violates the IMAP UID
| model which guarantees that a UID refers to an immutable object.  It isn't
| going to happen
|
| A way to work around the problem (and something that some people would
| probably like) would be a "copy message without listed attachments"
| command.  So, while you can't delete the attachment from the original
| message, you can make a copy of the message without the attachment and
| delete the original message.  The benefit of the new command would be that
| the client wouldn't have to download the message just to append it back;
| currently that's the only way to do "delete attachment".

That sounds a little like the 'compose on the server' extension for 
lemonade!

Actually, there is one potential way to get around the immutable message 
situation without caching problems with disconnected clients. Rather than 
delete the actual MIME part, the delete command would instead remove the 
MIME part content, but leave the MIME structure intact - i.e. fetching the 
MIME body returns nothing. Removal would also change the 
content-disposition on the removed parts to a new type of 'removed' with 
some ancillary parameters to indicate when it was removed etc.

How would this affect clients:

1) A client that has never seen the message before will not be affected, 
except for the fact that the user will see empty parts. The 
content-disposition can be used to show that the part content was deleted 
at some point in the past.

2) A client that has cached the entire message (mime structure and content) 
will not be affected as it will retrieve the mime content from its local 
cache.

3) A client that has cached the MIME structure but not the content: 
provided the client does not rely on the bodystructure size indicators (and 
of course it should not) there should be no problem about the fact that the 
client gets back zero bytes for the MIME body. The user may be surprised by 
this (as in situation 1) and it may be hard to determine exactly what 
happened as the cached bodystructure won't include the new 
content-disposition: removed indicator.

I think this is as close as you can get to an in-place attachment removal 
mechanism without causing caching problems for clients - however, the 
unexpected case in situation (3) may not be tolerable. Perhaps there are 
other issues I've not considered that would make this inappropriate?

-- 
Cyrus Daboo

Date: Tue, 4 Nov 2003 11:00:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: Re: Selective removal of attachments in a message
Organization: Networks & Distributed Computing
Sender: [email-masked]

It would be a nice feature to have; however, it violates the IMAP UID
model which guarantees that a UID refers to an immutable object.  It isn't
going to happen

A way to work around the problem (and something that some people would
probably like) would be a "copy message without listed attachments"
command.  So, while you can't delete the attachment from the original
message, you can make a copy of the message without the attachment and
delete the original message.  The benefit of the new command would be that
the client wouldn't have to download the message just to append it back;
currently that's the only way to do "delete attachment".

-- Mark --

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'IMAP Extensions WG'" <[email-masked]>
Cc: "'Madan Ganesh Velayudham'" <[email-masked]>
Subject: Selective removal of attachments in a message
Date: Wed, 5 Nov 2003 00:24:39 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C3A333.336AE950
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

	Please share your thoughts on the attached document.

	Sincerely,
	MG

	**************************
	Madan Ganesh Velayudham
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

------=_NextPart_000_0007_01C3A333.336AE950
Content-Type: text/plain;
	name="madanganeshv-remove-attachment-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="madanganeshv-remove-attachment-00.txt"

	REMOVE: Selective removal of attachments from a Message 
	=========================================================

Abstract

	Clients could want to remove attachments selectively from 
	a message in the mailbox. Currently there is no mechanism 
	by which a IMAP client can achieve this.

Overview :

	[RFC 3501] defines DELETE command to delete a mailbox and 
	store \Deleted + EXPUNGE sequence to permanently delete a
	message in a mailbox.

	There is no way by which a client can selectively delete/
	remove attachments or message parts from a message in a mailbox.
	
	As decribed in the Section 6.4.5 of [RFC 3501], every message
	has at least one part number.  Non-[MIME-IMB] messages, and non
	-multipart messages with no encapsulated message, only have a 
	part 1.

        Multipart messages are assigned consecutive part numbers, as
        they occur in the message.  If a particular part is of type
        message or multipart, its parts MUST be indicated by a period
        followed by the part number within that nested multipart part.

        A part of type MESSAGE/RFC822 also has nested part numbers,
        referring to parts of the MESSAGE part's body.              
        
        Clients can use REMOVE command to remove part(s) of message(s)
        in a mailbox.

CAPABILITY identification

	IMAP4 servers that support this extension MUST include an REMOVE
	capability response in teh response list to the CAPABILITY command.

REMOVE Command
	
  Arguments: sequence set
   	     message data item names
	
  Responses: untagged responses: REMOVE
	
  Result:    OK - Remove completed
  	     NO - Remove error
  	     BAD - Command Unknown
		   
  The REMOVE command removes part associated with a message in the mailbox.
    
Return codes and other issues
  
  	WORK IN PROGRESS
  
Security considerations
  
  	WORK IN PROGRESS
        
Author          
  
  Madan Ganesh Velayudham
  Hewlett-Packard
  
  [email-masked]
  +91-80-205-3108

------=_NextPart_000_0007_01C3A333.336AE950--

Date: Tue, 4 Nov 2003 08:43:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

On Tue, 4 Nov 2003, Pete Resnick wrote:
> >Probably URLAUTH needs at least a glance.
> I don't necessarily object to our discussing it (if we've got time),
> but aren't all of the "usual suspects" going to be in LEMONADE anyway?

Agreed, but an "IMAPEXT point of view" would be useful.

-- Mark --

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

Date: Tue, 4 Nov 2003 10:11:01 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Proposed agenda?
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/3/03 at 11:04 PM -0800, Mark Crispin wrote:

>Probably URLAUTH needs at least a glance.

I don't necessarily object to our discussing it (if we've got time), 
but aren't all of the "usual suspects" going to be in LEMONADE anyway?

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

Date: Mon, 3 Nov 2003 23:04:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

On Mon, 3 Nov 2003, Pete Resnick wrote:
> I'd very much like to hear from Chris Newman and Cyrus and/or Randy
> about what we will be discussing re: their documents. Anyone else
> have stuff to talk about?

Probably URLAUTH needs at least a glance.

-- Mark --

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

Date: Mon, 3 Nov 2003 21:06:46 -0600
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Proposed agenda?
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/1/03 at 2:40 PM +0000, Alexey Melnikov wrote:

>I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting.

I'd very much like to hear from Chris Newman and Cyrus and/or Randy 
about what we will be discussing re: their documents. Anyone else 
have stuff to talk about?

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

Date: Sat, 01 Nov 2003 15:49:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |
> | I still haven't heard any agenda proposals for Minneapolis IMAPEXT
> | meeting.
> | As I am not attending this meeting, I would like to know in advance 
> what
> | I am going to miss.
> |
> | Is there any point for doing a draft revision of ACL2 for people to
> | discuss in Minneapolis?
> | (I am a bit busy at work right now, so this is a selfish question. 
> But I
> | will produce something
> | if people think it is necessary/beneficial to discuss the document in
> | Minneapolis)
>
> How about the current document authors summarize the outstanding 
> issues with their docs on the list early next week and that can form 
> the basis for the agenda (or perhaps we can even resolve the issues on 
> the list before the meeting).

Ok.

CONDSTORE: I've sent private email to Application Area ADs with some 
clarifications. I got no response yet. Hopefully the answer would be 
that I need to do a minor revision to the document and no Last Call 
would be required.

ACL2: I've done nothing since August. I was reading various discussion 
threads, but I have yet to summarize required changes.

No changes to Keywords so far. I mostly agree with Mark on silly states 
and complicated dependencies, but I personally would like to keep 
certain keywords that he and Lyndon proposed to remove.

Revision of "disconnected clients" will come shortly after the 
Minneapolis meeting.

I've requested Ned/Ted to Last Call UNSELECT.

I've done almost nothing on QUOTA plus (draft-cridland-imap-quota-00.txt)

Alexey

Date: Sat, 01 Nov 2003 10:19:03 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda?
Sender: [email-masked]

Hi Alexey,

--On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov 
<[email-masked]> wrote:

|
| I still haven't heard any agenda proposals for Minneapolis IMAPEXT
| meeting.
| As I am not attending this meeting, I would like to know in advance what
| I am going to miss.
|
| Is there any point for doing a draft revision of ACL2 for people to
| discuss in Minneapolis?
| (I am a bit busy at work right now, so this is a selfish question. But I
| will produce something
| if people think it is necessary/beneficial to discuss the document in
| Minneapolis)

How about the current document authors summarise the outstanding issues 
with their docs on the list early next week and that can form the basis for 
the agenda (or perhaps we can even resolve the issues on the list before 
the meeting).

-- 
Cyrus Daboo

Date: Sat, 01 Nov 2003 14:40:31 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Proposed agenda?
Sender: [email-masked]

I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting.
As I am not attending this meeting, I would like to know in advance what 
I am going to miss.

Is there any point for doing a draft revision of ACL2 for people to 
discuss in Minneapolis?
(I am a bit busy at work right now, so this is a selfish question. But I 
will produce something
if people think it is necessary/beneficial to discuss the document in 
Minneapolis)

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 13:27:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked], Lyndon Nerenberg <[email-masked]>
Subject: Re: Jabbering - [email-masked]
Sender: [email-masked]

Pete Resnick wrote:

> On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote:
>
>> If serious discussions are going to take place on the jabber list, is 
>> it possible to have some summary of those posted to the email list
>
> Absolutely, though my feeling is that serious discussions should *not* 
> take place in jabber at this point. Jabber might be a nice way, if 
> someone happens to be around, to ask a quick "Hey, what's the status 
> of my draft?" or "I don't understand a piece of this draft. Can 
> someone explain what I'm missing, or should I bring this to the author 
> as a problem?" kind of question. I expect serious issue discussions to 
> always be on the list.

IMHO, Jabber is a very useful tool for real time communication with 
people who are unable to attend. And, IMHO, partial feedback is better 
than no feedback.
Of course it doesn't replace mailing list discussions.

Selecting a good scribe is a non trivial task (and makes a big 
difference). Maybe we should bribe well- known-good-scribes (e.g. 
Marshall Rose) ;-)?

Alexey