Subject: COPY/APPEND and ACLs
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Date: Thu, 28 Sep 2000 14:18:58 -0600
List-Id: <ietf-imapext.imc.org>

> s - keep seen/unseen information across sessions (STORE \SEEN flag)
> w - write (STORE flags other than \SEEN and \DELETED)
> d - delete messages (STORE \DELETED flag, perform EXPUNGE)

When doing COPY/APPEND should a server check for "s", "w" or  "d" when
it tries to set \Seen, \Deleted or other flags and drop the flags for
which a client has no rights? Or should the server ignore these rights
and copy all flags unconditionally?

Alexey

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-03.txt
Date: Fri, 22 Sep 2000 06:46:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-03.txt
	Pages		: 13
	Date		: 21-Sep-00
	
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-03.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-03.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-thread-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 15 Sep 2000 12:10:47 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Rationale for address sorting algorithm in SORT
To: Lyndon Nerenberg <[email-masked]>
cc: Chris Adie <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 15 Sep 2000 13:01:12 -0600 (MDT), Lyndon Nerenberg wrote:
> What about adding a FROMDOMAIN sort specifier that would sort on the
> domain component of the from address. This allows for (FROMDOMAIN
> FROM) which (for me at least) would be a very useful operation.
> (And add the complementary TODOMAIN and CCDOMAIN.)

Something on this line has already been suggested by Cyrus Daboo in the
context of "SORT2".  If SORT2 happens, there's no doubt in my mind that this
type of functionality must be part of it.

Date: Fri, 15 Sep 2000 13:01:12 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Chris Adie <[email-masked]>, [email-masked]
Subject: re: Rationale for address sorting algorithm in SORT
Sender: [email-masked]

What about adding a FROMDOMAIN sort specifier that would sort on the
domain component of the from address. This allows for (FROMDOMAIN
FROM) which (for me at least) would be a very useful operation.
(And add the complementary TODOMAIN and CCDOMAIN.)

--lyndon

Date: Fri, 15 Sep 2000 09:35:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Rationale for address sorting algorithm in SORT
To: Chris Adie <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Sep 2000 09:42:22 +0100, Chris Adie wrote:
> I'm interested in the rationale behind the address sorting algorithm in
> draft-ietf-imapext-sort-05.txt.
> [snip]
> Why was the local-part chosen instead of the addr-spec?

This is a good question.

Many people have multiple email addresses, although they tend to use the same
local-part for their multiple email addresses.  This is particularly true in
an academic environment

Absent a dictionary of equivalances, it's not possible to determine if
[email-masked] and [email-masked] are the same person or different.  As you
noted, matching just a local-part of "smith" would tend to yield false
positives.

On the other hand, failure to match local-part of "mrc" would tend to yield
false negatives.  False negatives turned out to be a big problem.

Fuzzy matching of the domain turns out to be a rathole.  It helps with
multiple addresses within an organization, but not with external addresses.
For example, many people here have both an UW address and an external address
at some ISP (e.g. [email-masked] and [email-masked]).

In the past decade with Pine, we've found that the user community is much more
tolerant of false positives than false negatives when sorting by FROM.  The
rule of matching by local-part only is inherited by this.  It's not laziness;
it's what generates the fewest bug reports.

Also, consider a (SUBJECT FROM) sort.  With false positives, you'll get
someone else's messages on the subject interspersed -- something that
everybody lives with all the time in reading email.  But with false negatives,
you'll have the same guy's messages out of order!

Fortunately, FROM sorting, not to mention something like (FROM SUBJECT)
sorting, isn't done all that often.  Most people choose threading instead.

This doesn't mean that I'm happy with the status quo; it's just that the other
choices have all been proven worse.

-- Mark --

From: "Chris Adie" <[email-masked]>
To: <[email-masked]>
Subject: Rationale for address sorting algorithm in SORT
Date: Fri, 15 Sep 2000 09:42:22 +0100
Sender: [email-masked]

I'm interested in the rationale behind the address sorting algorithm in
draft-ietf-imapext-sort-05.txt.

The CC, FROM and TO criteria are sorted on the RFC822 local-part of the first
address, rather than on the local-part@domain.  I believe this has bad effects.
For instance, suppose I have three messages:

Message 1 from [email-masked] subject Aardvarks
Message 2 from [email-masked] subject Zip drives
Message 3 from [email-masked] subject Middleware

If I sort on (FROM SUBJECT), the resulting order according to the spec is 1 3
2, which is bad.  Most people would expect that sorting by the FROM field
should group all the messages from a single person together.

If the sort algorithm worked on local-part@domain (ie addr-spec in RFC822
terms) instead, then the order would be 1 2 3, which seems much more natural.

Why was the local-part chosen instead of the addr-spec?

Chris Adie

From: [email-masked]
To: <[email-masked]>
Date: Thu, 14 Sep 2000 05:18:16
Subject: 
Sender: [email-masked]

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  

Webhosting International

 

 

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapv-10.txt
Date: Wed, 13 Sep 2000 06:55:39 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapv-10.txt
	Pages		: 93
	Date		: 12-Sep-00
	
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server.  IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders.  IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server (see also [IMAP-DISC]).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapv-10.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-crispin-imapv-10.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapv-10.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 8 Sep 2000 19:06:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Summary: SORT/THREAD/VIEW debate
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 08 Sep 2000 17:45:44 -0700, Chris Newman wrote:
> I haven't seen any comments on my attempt at a summary of the debate.  Can
> I presume the summary was largely accurate?

That is quite presumptious.  A summary of a debate is produced by an impartial
third party, who secures the agreement of the advocates that their positions
are fairly represented.

I do not wish to review or comment on your representation of my position.

> While the points of contention listed below were discussed briefly at the
> WG meeting in Pittsburgh, I do not believe all ramifications were
> considered and all positions adequately presented.  Therefore, barring a
> rough concensus on the list prior to that time, I believe these points of
> contention should be considered unresolved and discussed at the IETF
> meeting in San Jose.

Although I do not disagree that the points of contention are unresolved,
neither you nor I should make statements such as the above.  Advocates can not
simultaneously be moderators.

It may be necessary for someone to lead this debate, but that someone is
neither you nor I.

Date: Fri, 08 Sep 2000 17:45:44 -0700
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Summary: SORT/THREAD/VIEW debate
Sender: [email-masked]

I haven't seen any comments on my attempt at a summary of the debate.  Can 
I presume the summary was largely accurate?

While the points of contention listed below were discussed briefly at the 
WG meeting in Pittsburgh, I do not believe all ramifications were 
considered and all positions adequately presented.  Therefore, barring a 
rough concensus on the list prior to that time, I believe these points of 
contention should be considered unresolved and discussed at the IETF 
meeting in San Jose.

--On Friday, August 25, 2000 12:05 -0700 Chris Newman 
<[email-masked]> wrote:
> The points of contention are:
> ...
> (1) Whether it is desirable to standardize a one-shot SORT/THREAD facility
>     given a persistant SORT/THREAD facility will also be standardized.
> ...
> (2) Desire for scalability on the basis of mailbox size (Windowing).
> ...
> (3) Desire to collapse related functionality into a minimal number of
>     capability items.

		- Chris

Date: Thu, 28 Sep 2000 14:18:58 -0600
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: COPY/APPEND and ACLs
Sender: [email-masked]

> s - keep seen/unseen information across sessions (STORE \SEEN flag)
> w - write (STORE flags other than \SEEN and \DELETED)
> d - delete messages (STORE \DELETED flag, perform EXPUNGE)

When doing COPY/APPEND should a server check for "s", "w" or  "d" when
it tries to set \Seen, \Deleted or other flags and drop the flags for
which a client has no rights? Or should the server ignore these rights
and copy all flags unconditionally?

Alexey

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-03.txt
Date: Fri, 22 Sep 2000 06:46:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-03.txt
	Pages		: 13
	Date		: 21-Sep-00
	
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-03.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-03.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-thread-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 15 Sep 2000 12:10:47 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Rationale for address sorting algorithm in SORT
To: Lyndon Nerenberg <[email-masked]>
cc: Chris Adie <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 15 Sep 2000 13:01:12 -0600 (MDT), Lyndon Nerenberg wrote:
> What about adding a FROMDOMAIN sort specifier that would sort on the
> domain component of the from address. This allows for (FROMDOMAIN
> FROM) which (for me at least) would be a very useful operation.
> (And add the complementary TODOMAIN and CCDOMAIN.)

Something on this line has already been suggested by Cyrus Daboo in the
context of "SORT2".  If SORT2 happens, there's no doubt in my mind that this
type of functionality must be part of it.

Date: Fri, 15 Sep 2000 13:01:12 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Chris Adie <[email-masked]>, [email-masked]
Subject: re: Rationale for address sorting algorithm in SORT
Sender: [email-masked]

What about adding a FROMDOMAIN sort specifier that would sort on the
domain component of the from address. This allows for (FROMDOMAIN
FROM) which (for me at least) would be a very useful operation.
(And add the complementary TODOMAIN and CCDOMAIN.)

--lyndon

Date: Fri, 15 Sep 2000 09:35:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Rationale for address sorting algorithm in SORT
To: Chris Adie <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Sep 2000 09:42:22 +0100, Chris Adie wrote:
> I'm interested in the rationale behind the address sorting algorithm in
> draft-ietf-imapext-sort-05.txt.
> [snip]
> Why was the local-part chosen instead of the addr-spec?

This is a good question.

Many people have multiple email addresses, although they tend to use the same
local-part for their multiple email addresses.  This is particularly true in
an academic environment

Absent a dictionary of equivalances, it's not possible to determine if
[email-masked] and [email-masked] are the same person or different.  As you
noted, matching just a local-part of "smith" would tend to yield false
positives.

On the other hand, failure to match local-part of "mrc" would tend to yield
false negatives.  False negatives turned out to be a big problem.

Fuzzy matching of the domain turns out to be a rathole.  It helps with
multiple addresses within an organization, but not with external addresses.
For example, many people here have both an UW address and an external address
at some ISP (e.g. [email-masked] and [email-masked]).

In the past decade with Pine, we've found that the user community is much more
tolerant of false positives than false negatives when sorting by FROM.  The
rule of matching by local-part only is inherited by this.  It's not laziness;
it's what generates the fewest bug reports.

Also, consider a (SUBJECT FROM) sort.  With false positives, you'll get
someone else's messages on the subject interspersed -- something that
everybody lives with all the time in reading email.  But with false negatives,
you'll have the same guy's messages out of order!

Fortunately, FROM sorting, not to mention something like (FROM SUBJECT)
sorting, isn't done all that often.  Most people choose threading instead.

This doesn't mean that I'm happy with the status quo; it's just that the other
choices have all been proven worse.

-- Mark --

From: "Chris Adie" <[email-masked]>
To: <[email-masked]>
Subject: Rationale for address sorting algorithm in SORT
Date: Fri, 15 Sep 2000 09:42:22 +0100
Sender: [email-masked]

I'm interested in the rationale behind the address sorting algorithm in
draft-ietf-imapext-sort-05.txt.

The CC, FROM and TO criteria are sorted on the RFC822 local-part of the first
address, rather than on the local-part@domain.  I believe this has bad effects.
For instance, suppose I have three messages:

Message 1 from [email-masked] subject Aardvarks
Message 2 from [email-masked] subject Zip drives
Message 3 from [email-masked] subject Middleware

If I sort on (FROM SUBJECT), the resulting order according to the spec is 1 3
2, which is bad.  Most people would expect that sorting by the FROM field
should group all the messages from a single person together.

If the sort algorithm worked on local-part@domain (ie addr-spec in RFC822
terms) instead, then the order would be 1 2 3, which seems much more natural.

Why was the local-part chosen instead of the addr-spec?

Chris Adie

From: [email-masked]
To: <[email-masked]>
Date: Thu, 14 Sep 2000 05:18:16
Subject: 
Sender: [email-masked]

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  

Webhosting International

 

 

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapv-10.txt
Date: Wed, 13 Sep 2000 06:55:39 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapv-10.txt
	Pages		: 93
	Date		: 12-Sep-00
	
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server.  IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders.  IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server (see also [IMAP-DISC]).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapv-10.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-crispin-imapv-10.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapv-10.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 8 Sep 2000 19:06:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Summary: SORT/THREAD/VIEW debate
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 08 Sep 2000 17:45:44 -0700, Chris Newman wrote:
> I haven't seen any comments on my attempt at a summary of the debate.  Can
> I presume the summary was largely accurate?

That is quite presumptious.  A summary of a debate is produced by an impartial
third party, who secures the agreement of the advocates that their positions
are fairly represented.

I do not wish to review or comment on your representation of my position.

> While the points of contention listed below were discussed briefly at the
> WG meeting in Pittsburgh, I do not believe all ramifications were
> considered and all positions adequately presented.  Therefore, barring a
> rough concensus on the list prior to that time, I believe these points of
> contention should be considered unresolved and discussed at the IETF
> meeting in San Jose.

Although I do not disagree that the points of contention are unresolved,
neither you nor I should make statements such as the above.  Advocates can not
simultaneously be moderators.

It may be necessary for someone to lead this debate, but that someone is
neither you nor I.

Date: Fri, 08 Sep 2000 17:45:44 -0700
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Summary: SORT/THREAD/VIEW debate
Sender: [email-masked]

I haven't seen any comments on my attempt at a summary of the debate.  Can 
I presume the summary was largely accurate?

While the points of contention listed below were discussed briefly at the 
WG meeting in Pittsburgh, I do not believe all ramifications were 
considered and all positions adequately presented.  Therefore, barring a 
rough concensus on the list prior to that time, I believe these points of 
contention should be considered unresolved and discussed at the IETF 
meeting in San Jose.

--On Friday, August 25, 2000 12:05 -0700 Chris Newman 
<[email-masked]> wrote:
> The points of contention are:
> ...
> (1) Whether it is desirable to standardize a one-shot SORT/THREAD facility
>     given a persistant SORT/THREAD facility will also be standardized.
> ...
> (2) Desire for scalability on the basis of mailbox size (Windowing).
> ...
> (3) Desire to collapse related functionality into a minimal number of
>     capability items.

		- Chris