headers
Internet-Drafts | 4 Jan 2001 13:27
Picon
Favicon

I-D ACTION:draft-ietf-imapext-sort-06.txt

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-06.txt
	Pages		: 10
	Date		: 03-Jan-01
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the
SORT2 extension.

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

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

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 4 Jan 2001 13:27
Picon
Favicon

I-D ACTION:draft-ietf-imapext-thread-06.txt

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-06.txt
	Pages		: 13
	Date		: 03-Jan-01
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

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

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

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

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 5 Jan 2001 04:44

LAST CALL: IMAP base and MULTIAPPEND drafts

As discussed in the IMAPEXT meeting in San Diego,...

This is a last call for
 http://www.ietf.org/internet-drafts/draft-crispin-imapv-13.txt
which is the latest revision of RFC 2060, correcting all known errors and
omissions.  It has been 4 years since RFC 2060 was released, and there are
a lot of changes and clarifications.

This is also a last call for
 http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-02.txt
which is a minor (but exceedingly useful) extension.  It is unchanged from
the -01 draft except for an updated expiration date.

Does IMAPEXT want to take on MULTIAPPEND, or just let it advance to
Proposed Standard status by itself?  I don't forsee any further work being
done to MULTIAPPEND, and people have been implementing it...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Permalink | Reply | 6 comments |
headers
Simon Josefsson | 5 Jan 2001 13:06
Favicon

Re: LAST CALL: IMAP base and MULTIAPPEND drafts

Mark Crispin <mrc <at> cac.washington.edu> writes:

> This is also a last call for
>  http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-02.txt
> which is a minor (but exceedingly useful) extension.  It is unchanged from
> the -01 draft except for an updated expiration date.

I haven't had time to read this draft until now, so this is a late
minor clearification of two points...  Sorry for late reaction.

Suggestion, replace:

      The APPEND command appends the literal arguments as new messages
      to the end of the specified destination mailbox.  This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.

with

      The APPEND command appends the literal arguments as new messages
      to the end of the specified destination mailbox.  This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message body.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Crispin | 5 Jan 2001 20:24

Re: LAST CALL: IMAP base and MULTIAPPEND drafts

On 05 Jan 2001 13:06:45 +0100, Simon Josefsson wrote:
> Suggestion, replace:
>       8-bit characters
>       are permitted in the message.
> with
>       8-bit characters
>       are permitted in the message body.
> since 8-bit characters are not permitted at all in the header section
> of a message, I think.

Nominally, this is a good idea.  However, I have not made this change, and
unless there is strong concensus for it I don't intend to do so, for the
following reasons:

 1) it would require that both the IMAP base (which has similar wording) and
IMAP MULTIAPPEND documents be revised if 8-bit characters are ever allowed in
the header.  I'm thinking of the time when all the world is Unicode and we can
dispense with all other charsets, encoded words, etc.

 2) There is also the question of allowing APPEND for messages that don't
necessarily conform to RFC 822; this is particularly an issue with drafts.

There seems to be a concensus (which I share) that IMAP servers should not
attempt to do message format validation on APPEND because of the issue with
drafts.  However, if such validation is done, I feel that the specification of
the validation should be in the message format document (RFC 822 or successor)
and not in an IMAP document.  As far as the IMAP document is concerned, the
APPEND text is simply a literal.

> Also, regarding UIDPLUS interactions, I'd suggest replacing
(Continue reading)

Permalink | Reply | 4 comments |
headers
Edward Hibbert | 17 Jan 2001 22:47
Favicon

Move?

I'm sure this is going to turn out to be a stupid question.

There's a COPY command to copy an item from one mailbox to another.  But so
far as I'm aware there isn't a MOVE command, so a client has to do a COPY
and then a DELETE (and possibly an EXPUNGE if it wants the item to disappear
from its view of the current folder, depending on how it presents this).

Is there any particular reason why there isn't a MOVE command?

Edward Hibbert
Internet Applications Group
Data Connection Ltd
Tel:	+44 131 662 1212		Fax:	+44 131 662 1345
Email:	eh <at> dataconnection.com	Web:	http://www.dataconnection.com
Permalink | Reply | 1 comment |
headers
Mark Crispin | 17 Jan 2001 22:52

re: Move?

On Wed, 17 Jan 2001 21:47:16 -0000, Edward Hibbert wrote:
> There's a COPY command to copy an item from one mailbox to another.  But so
> far as I'm aware there isn't a MOVE command, so a client has to do a COPY
> and then a DELETE (and possibly an EXPUNGE if it wants the item to disappear
> from its view of the current folder, depending on how it presents this).

That is correct.

> Is there any particular reason why there isn't a MOVE command?

You just gave the reason: the functionality of a MOVE command can be done with
the existing commands.  It also preserves the IMAP delete-expunge model in
which it is impossible to remove a message from a mailbox in a single step.

The obvious temptation for implementations which have a one-file/one-message
form of mail store would be to implement MOVE via a rename() system call; it's
also the primary motivation for asking for it (the secondary reason is to
eliminate the additional RTT).  That violates the IMAP delete-expunge model.

An additional problem which is often overlooked with rename() is that COPY
requires that the operation succeed or fail atomicly.  There is no atomic
rename(); which means that if a rename() fails (e.g. due to disk quota in the
target) the previous messages have to be rename()d back -- which could also
fail!

The bottom line here is that the rename() idea is an "attractive nuisance";
one that looks desirable on the surface but has serious problems.  Since these
problems are not necessarily obvious, affirmative measures need to be in place
to prevent it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Hibbert | 18 Jan 2001 10:06
Favicon

RE: Move?

My motivation for a MOVE is not based on an infatuation with OS commands
:-).  I have a nice transactional database with rollback and all that good
stuff.

Instead it's about quota.  At the moment we enforce the quota limit on the
COPY command.  We have come up against a client which maintains a Deleted
Items folder (mailbox in IMAP terminology), so it moves items into it when
the user deletes them.  To do the move it does a COPY/DELETE/EXPUNGE.  

But this process requires that you have as much free quota as the size of
the message you're trying to move - which is obviously not possible if the
message is itself more than half your quota limit.

Changing the client is not really an option, so I'm left with couple of
ideas, neither of which I like very much:
- don't check quota on COPY
- hardcode the Deleted Items folder name and don't check quota if we're
copying to there.

Obviously with a MOVE command it would be clear that you weren't trying to
violate your quota.  It wouldn't help me just now because I can't change the
client to use it, but it seems to me that this is an argument in favour of
it.

Do any of you folk have any other ideas as to how to solve this?

Regards,

Edward Hibbert
Internet Applications Group
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Haxby | 18 Jan 2001 10:50
Picon

Re: Move?

Edward Hibbert wrote:

> My motivation for a MOVE is not based on an infatuation with OS commands
> :-).  I have a nice transactional database with rollback and all that good
> stuff.
>
> Instead it's about quota.  At the moment we enforce the quota limit on the
> COPY command.  We have come up against a client which maintains a Deleted
> Items folder (mailbox in IMAP terminology), so it moves items into it when
> the user deletes them.  To do the move it does a COPY/DELETE/EXPUNGE.
>
> But this process requires that you have as much free quota as the size of
> the message you're trying to move - which is obviously not possible if the
> message is itself more than half your quota limit.

We have exactly this problem as well.   We just ignore the limitation.  At some
stage, someone will complain and then we might have to do something about it.
I have also given up on the idea of having a DELETE command as well.   (Quite
apart from the various race conditions in a mark/delete scheme, we get problems
with users who delete a message but since the client doesn't actually delete it
just yet, you don't drop below quota.   One of these days, someone is going to
decide that merely modifying messages when you are over quota is a bad move and
you won't be able to get below it again...)

jch, dispirited
Attachment (jch.vcf): text/x-vcard, 476 bytes
Permalink | Reply | 0 comments |
headers
Ken Murchison | 18 Jan 2001 18:46

Re: Move?


Edward Hibbert wrote:
> 
> My motivation for a MOVE is not based on an infatuation with OS commands
> :-).  I have a nice transactional database with rollback and all that good
> stuff.
> 
> Instead it's about quota.  At the moment we enforce the quota limit on the
> COPY command.  We have come up against a client which maintains a Deleted
> Items folder (mailbox in IMAP terminology), so it moves items into it when
> the user deletes them.  To do the move it does a COPY/DELETE/EXPUNGE.
> 
> But this process requires that you have as much free quota as the size of
> the message you're trying to move - which is obviously not possible if the
> message is itself more than half your quota limit.
> 
> Changing the client is not really an option, so I'm left with couple of
> ideas, neither of which I like very much:
> - don't check quota on COPY
> - hardcode the Deleted Items folder name and don't check quota if we're
> copying to there.
> 
> Obviously with a MOVE command it would be clear that you weren't trying to
> violate your quota.  It wouldn't help me just now because I can't change the
> client to use it, but it seems to me that this is an argument in favour of
> it.
> 
> Do any of you folk have any other ideas as to how to solve this?

We had a similar problem here with people using Communicator with a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane