Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
From: Mark Crispin <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Fri, 18 Feb 2000 20:59:29 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

On Fri, 18 Feb 2000 23:49:13 -0500, Tony Hansen wrote:
> Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1,
> but was. Since we've started down the path of using "revX", shouldn't it
> be continued?

There were incompatible changes between RFC 1730 and RFC 2060.  Specifically,
poorly-designed RFC 1730 features relating to partial fetching were deleted
from the IMAP specification, and much better features added in RFC 2060.

A vendor insisted that it had to be possible to distinguish between RFC 1730
and RFC 2060 servers.  It's a long story, but my arm was severely twisted to
create "IMAP4rev1" (what an ugly name!).  No, it was not the Evil Empire.

Of course, nobody actually depended upon the broken features of RFC 1730 (if
you tried to implement them, you'd find out why...) and everybody thinks that
RFC 2060 is the one true IMAP (as they should).  But we're apparently stuck
with that "rev1" suffix forever.

This is not the case with the new draft.  The vast majority of the draft
consists of clarifications of what is in RFC 2060.  There's a small handful of
new status codes.  Nevertheless, there's no reason for a strict RFC 2060
implementation to have any problem with an implementation that supports the
new draft or vice versa.

Date: Fri, 18 Feb 2000 23:49:13 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
Sender: [email-masked]

Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1,
but was. Since we've started down the path of using "revX", shouldn't it
be continued?

	Tony Hansen
	[email-masked]

Mark Crispin wrote:
> 
> I would like to make a last call on the IMAPV document, which is
> essentially a bugfix update to RFC 2060.  Please read and review it,
> since I would like to submit it as an RFC as the new standards-track
> bas IMAP specification.
> 
> ---------- Forwarded message ----------
> Subject: I-D ACTION:draft-crispin-imapv-09.txt
> 
> 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-09.txt

Date: Fri, 18 Feb 2000 18:33:32 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

I would like to make a last call on the IMAPV document, which is
essentially a bugfix update to RFC 2060.  Please read and review it, since
I would like to submit it as an RFC as the new standards-track bas IMAP
specification.

---------- Forwarded message ----------
Date: Thu, 17 Feb 2000 06:27:25 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapv-09.txt

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-09.txt
	Pages		: 93
	Date		: 16-Feb-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]).
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes; checking for new messages; permanently removing messages;
setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
searching; and selective fetching of message attributes, texts, and
numbers.  These numbers are either message sequence numbers or unique
identifiers.
IMAP4rev1 supports a single server.  A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols.  In the course of the evolution of
IMAP4rev1, some aspects in the earlier protocol have become obsolete.
Obsolete commands, responses, and data formats which an IMAP4rev1
implementation can encounter when used with an earlier implementation
are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT].  A full
discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapv-09.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-09.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-09.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
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imapv-09.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Wed, 16 Feb 2000 12:23:11 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Pete Resnick <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

For what it's worth, I had not planned to go to Adelaide.  I made multiple
inquiries to see if anything IMAP-relevant would go on there, with no answer.
Even if I make arrangements to do, I can not get to Adelaide until Tuesday at
the swiftest due to other commitments.

I don't think that there is a controversy.  I haven't heard of anybody in IMAP
or IMAPEXT who wants to charter IMAPEXT with base spec work on its agenda.
IESG should be told that the unanimous opinion of the IMAP community is a
rejection of this notion.

On Wed, 16 Feb 2000 11:22:18 -0600, Pete Resnick wrote:
> Unless this round of discussion on the list has convinced the people
> in question, I think there has been enough indication of controversy
> that a WG/BOF meeting be scheduled at Adelaide at which time we
> should work this out. Members of the IAB/IESG who think the base spec
> work item should be added to the charter ought to be present.

Date: Wed, 16 Feb 2000 11:22:18 -0600
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: IMAPEXT Chartering
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

I promised not to make a comment on this topic, but it seems that 
most folks who are going to chime in have done so. So, first with my 
chairman hat off:

On 2/7/00 at 3:09 PM +0100, Patrik Fältström wrote:

>How, when, where would you suggest a review of the base spec is done?

The base spec is being worked on right now and may be about to go to 
last call. It can get review during this time, and if there are folks 
who think that progressing it should be held up until an 
informational document is produced, they can hold up this rev of the 
base spec. If a working group is required to get that job done, one 
can be formed. This can be done independently and in parallel with 
IMAPEXT.

>If that is done in parallell, do you think other people will work 
>with base spec than IMAPEXT issues?

There will clearly be a huge intersection of people. That's 
irrelevant. Combining the two activities almost guarantees leakage 
between the two topics. I can hear it now: "Oh, that problem with the 
base spec can be solved with an extension; let's just add that to our 
charter." Or even better, "That extension will work if we make one 
little change to the base spec; let's do that during the base spec 
review." This has disaster written all over it. Keeping the 
activities separate forces the extensions to be clean and independent 
of base spec changes and forces base spec cleanups (if needed) to not 
be kludges.

Now, with my chairman hat on:

Unless this round of discussion on the list has convinced the people 
in question, I think there has been enough indication of controversy 
that a WG/BOF meeting be scheduled at Adelaide at which time we 
should work this out. Members of the IAB/IESG who think the base spec 
work item should be added to the charter ought to be present.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 16 Feb 2000 10:26:59 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On Tuesday, February 15, 2000 7:20 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> I agree.  But I dread making a last call.  The silence in the past several
> months (years, actually) of various imapv drafts frightens me.  I just
> know that there won't be any feedback until there's a last call, then
> suddenly will come vehement demands for massive rewrites or new text.
>
> OK, I am sending out draft 09 today.  The only changes from 08 are
> pointing out how % works with LSUB and clarify the "don't use STATUS on
> the selected mailbox rule."
>
> PS: I didn't call it "imapv", the I-D editor did for reasons which are
> still unclear to me...ours is not to question why, ours is but to do or...

Well given the negative response on this list to the idea of revising the 
base-spec as a whole I don't see how there could be major objections to 
"imapv" and resulting rewrites of "imapv". So personally I think you should 
last call it.

-- 
Cyrus

Date: Tue, 15 Feb 2000 19:20:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Tue, 15 Feb 2000 14:16:00 -0500, Cyrus Daboo wrote:
> Agreed. But should we not pursue making the current 'imapv' draft an RFC?

I agree.  But I dread making a last call.  The silence in the past several
months (years, actually) of various imapv drafts frightens me.  I just know
that there won't be any feedback until there's a last call, then suddenly will
come vehement demands for massive rewrites or new text.

OK, I am sending out draft 09 today.  The only changes from 08 are pointing
out how % works with LSUB and clarify the "don't use STATUS on the selected
mailbox rule."

PS: I didn't call it "imapv", the I-D editor did for reasons which are still
unclear to me...ours is not to question why, ours is but to do or...

Date: Tue, 15 Feb 2000 14:16:00 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On Tuesday, February 15, 2000 10:48 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> For what it's worth, I agree with all of the comments which oppose a
> refresh of the base IMAP spec, for the reasons given.
>
> If people have a problem with reading ABNF and want to implement from
> examples, then the obvious solution is to flush all the examples from the
> base spec.  ;-)

Agreed. But should we not pursue making the current 'imapv' draft an RFC? 
There are quite a few corrections (minor) and some additions (also minor) 
making a total of 61 changes in the -08 draft that would be nice to see as 
a 'proper' RFC, updating 2060. I've come across some people that are 
reluctant to make these changes in their products because they are not in a 
'proper' RFC.

-- 
Cyrus

Date: Tue, 15 Feb 2000 10:48:14 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Steve Hole <[email-masked]>
cc: Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

For what it's worth, I agree with all of the comments which oppose a refresh
of the base IMAP spec, for the reasons given.

If people have a problem with reading ABNF and want to implement from
examples, then the obvious solution is to flush all the examples from the base
spec.  ;-)

From: Steve Hole <[email-masked]>
Date: Mon, 14 Feb 2000 22:10:28 -0700
To: Pete Resnick <[email-masked]>
Subject: Re: IMAPEXT Chartering
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Sun, 6 Feb 2000 14:05:18 -0600 Pete Resnick <[email-masked]> 
wrote:

> Return-Path: <[email-masked]>
> Date: Sun, 06 Feb 2000 20:41:33 +0100
> From: Patrik Fältström <[email-masked]>
> To: Pete Resnick <[email-masked]>
> cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>
> Subject: Re: IMAPEXT progress?
> 
> --On 2000-02-03 16.41 -0600, Pete Resnick <[email-masked]> wrote:
> 
> >  Anything going on with regard to the chartering of IMAPEXT?
> 
> After discussing this for some time among some IESG and IAB members, we
> have agreed that this is a go _IF_ you add to the charter a refreshment of
> the base IMAP spec.
> 
> Yes, we know you don't like it, and we don't normally do it this way. I.e.
> a wg working with extensions should not also do the base spec. It is also
> the case that we normally (as you know personally ;-) want people to first
> do the boring stuff, and then get to the dessert.
> 
> But, in the case of IMAP, we feel that many people work really hard, and
> the same people would work on the extensions _and_ the base spec. Because
> of this, we don't see any need for two working groups.

I cannot believe that this is a good idea.   (1) it implies that there is 
a lot of work to do on the base specification, which is not true, and (2) 
it will delay the extension work substantially.

I suspect that I know where much of this request originated.  The bottom 
line is that, with the exception of the NAMESPACE extension, 
interoperability is pretty decent these days.    Some people still have a 
problem reading ABNF and want to implement from the examples, but that is 
not a problem for IMAP in particular.   Frankly, we seem to have a lot 
more problem with MIME and S/MIME interoperability than we do with IMAP.

There are some things that can be done to improve the capability and 
useability of IMAP.    Most of these can be addressed as extensions.   I 
really see no reason to take on this work.

Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Tue, 15 Feb 2000 12:00:31 +0000
To: [email-masked], [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd)
Sender: [email-masked]

The formal syntax used in draft-crispin-imap-multiappend-00.txt seems to
have fallen between two stools, it follows neither RFC2234 nor RFC2060.

Assuming that the syntax is supposed to conform to RFC2234 (as does
draft-crispin-imapv-08.txt) then replace SPACE with SP and _ with -
throughout

>
>Modification to IMAP4rev1 Base Protocol Formal Syntax
>
>   append          = "APPEND" SPACE mailbox 1*append_message
>
>   append-message  = [SPACE flag_list] [SPACE date_time] SPACE literal
>
>
>MULTIAPPEND Interaction with UIDPLUS Extension
>
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>
>   resp-code-apnd  = "APPENDUID" SPACE nz_number 1*(SPACE uniqueid)
>

Becomes

Modification to IMAP4rev1 Base Protocol Formal Syntax

   append          = "APPEND" SP mailbox 1*append-message

   append-message  = [SP flag-list] [SP date-time] SP literal

MULTIAPPEND Interaction with UIDPLUS Extension

   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
   "resp-code-apnd" rule modified as follows:

   resp-code-apnd  = "APPENDUID" SP nz-number 1*(SP uniqueid)

On the other hand if it is not intended to conform to RFC2234 but to
follow RFC2060 then replace = with ::= and - with _ throughout.

Regards 

-- 
Paul Overell                                             T U R N P I K E

Date: Mon, 14 Feb 2000 08:21:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
cc: IMAP Interest List <[email-masked]>
Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

As promised, here is the specification for MULTIAPPEND.  Preliminary
testing of the c-client implementation shows that it is a major winner,
and much less kludgy than streaming appends!

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

---------- Forwarded message ----------
Date: Mon, 14 Feb 2000 06:44:26 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND      
                          EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imap-multiappend-00.txt
	Pages		: 5
	Date		: 11-Feb-00
	
This document describes the multiappending extension to the [IMAP]
protocol.  This extension provides substantial performance
improvements for IMAP clients which upload multiple messages at a
time to a mailbox on the server.
A server which supports this extension indicates this with a
capability name of 'MULTIAPPEND'.

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

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

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

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

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

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

--NextPart
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Tue, 8 Feb 2000 11:45:13 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2 forwarded messages...
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--16819560-1488665461-950039113=:29569
Content-Type: TEXT/PLAIN; charset=US-ASCII

I've re-posted the SORT and THREAD drafts, since the old ones are
expiring.  There are no changes in either other than the obvious
editorial ones.

Since it's been 6 months, I would like to call a "last call" for the SORT
draft to be submitted to the IESG for publication as an Informational or
Experimental RFC.  Once that has been done, I will reconstitute the SORT
draft as a working document of IMAPEXT (called SORT+ or SORTrev1 or
whatever) and then we can talk about the addressions to go into it.

I would like group input on what to do about THREAD.  I suggest that we
should just go and publish THREAD as a Proposed Standard, on the grounds
that THREAD can be extended arbitrarily (ala SASL) and, as in SASL, it
makes no sense to block advancement of the framework just because some of
the algorithms aren't fully specified yet.  In any case, I agree that we
have add the missing algorithms (for In-Reply-To and References threading)
prior to it getting beyond Proposed, either in the THREAD document or as
auxillary documents.

Bottom line on my recommendations:

1) Push SORT to informational/experimental RFC now.
2) Start standards-track SORTxxx draft, with SORT RFC as its basis.
3) Push THREAD to proposed standard RFC now, even though
    THREAD=ORDEREDSUBJECT is the only algorithm defined as yet.
4) Start THREAD=INREPLYTO and THREAD=REFERENCES draft.

The documents in (2) and (4) would be IMAPEXT WG documents.

--16819560-1488665461-950039113=:29569
Content-Type: MULTIPART/Digest; BOUNDARY="16819560-719432153-950039113=:29569"
Content-ID: <[email-masked]>
Content-Description: Digest of 2 messages

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--16819560-719432153-950039113=:29569
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <[email-masked]>
Content-Description: I-D ACTION:draft-crispin-imapext-sort-01.txt (fwd)

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapext-sort-01.txt
Date: Tue, 08 Feb 2000 06:31:30 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-sort-01.txt
	Pages		: 9
	Date		: 07-Feb-00
	
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-crispin-imapext-sort-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapext-sort-01.txt

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

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

--OtherAccess--

--NextPart--

--16819560-719432153-950039113=:29569
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <[email-masked]>
Content-Description: I-D ACTION:draft-crispin-imapext-thread-01.txt (fwd)

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapext-thread-01.txt
Date: Tue, 08 Feb 2000 06:32:52 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-thread-01.txt
	Pages		: 7
	Date		: 07-Feb-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-crispin-imapext-thread-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapext-thread-01.txt

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

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

--OtherAccess--

--NextPart--

--16819560-719432153-950039113=:29569--
--16819560-1488665461-950039113=:29569--

Date: Mon, 7 Feb 2000 16:50:36 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering 
To: Mike Gahrns <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

I agree completely with Mike Gahrns' comments.

It is not clear to me that WG action is required on the base spec.  We may
want to draw up a list of which points from Barry's document should go in the
base spec, but those should be held to clarifications (or possibly
prohibitions).

The only extension which *may* belong in the base spec is STARTTLS.  None of
the other extensions are of such vital importance that a server must have it
or be considered broken.  At least one of the extensions (NAMESPACE) has been
known to create problems with certain (we all know which) clients.

From: "Mike Gahrns" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: "IMAP Extensions" <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 7 Feb 2000 16:27:10 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BF7188.2EC42280
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: IMAPEXT CharteringI agree with Lyndon and others to do the review of =
the base spec after any extensions are done.  (Assuming that a review of =
the base spec needs to be in the IMAPEXT charter, which I don't think is =
the case).

I also wonder if the perceived need of doing a review of the base spec =
is based upon the state of IMAP interoperability a fews ago.

My personal opinion is that IMAP interoperability is now good.  =
Admittedly there are some implementations that may not do things in the =
most efficient manner, and may not take full advantage of the protocol, =
but I think we are at a point now where interop between various vendor's =
IMAP client's and servers is decent.  I think the results from the =
various IMC mail connects bear this out.  The group definitely did iron =
out some kink in some implementations as a result of these events, and =
the group also worked quite hard on the "implementor's guide" that barry =
leiba put together.  As a result, IMAP interop today is probably better =
than some people may perceive it to be.

------=_NextPart_000_0008_01BF7188.2EC42280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: IMAPEXT Chartering</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I agree with Lyndon and others to do =
the review of=20
the base spec after any extensions are done.&nbsp; (Assuming that a =
review of=20
the base spec needs to be in the IMAPEXT charter, which I don't think is =
the=20
case).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I also wonder if the perceived need of =
doing a=20
review of the base spec is based upon the state of IMAP interoperability =
a fews=20
ago.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My&nbsp;personal opinion is that IMAP=20
interoperability is now&nbsp;good.&nbsp; Admittedly there are some=20
implementations that may not do things in the most efficient manner, and =
may not=20
take full advantage of the protocol, but I think we are at a point now =
where=20
interop between various vendor's IMAP client's and servers =
is&nbsp;decent.&nbsp;=20
I think the results from the various IMC mail connects&nbsp;bear this =
out.&nbsp;=20
The group definitely did iron out some kink in some =
implementations&nbsp;as a=20
result of these events, and the group also worked quite hard on the=20
"implementor's guide" that barry leiba put together.&nbsp; As a result, =
IMAP=20
interop today is probably better than some people may perceive it to=20
be.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01BF7188.2EC42280--

From: Lyndon Nerenberg <[email-masked]>
To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 07 Feb 2000 08:11:11 -0700
Sender: [email-masked]

>>>>> "Patrik" == Patrik Fältström <[email-masked]> writes:

    Patrik> How, when, where would you suggest a review of the base
    Patrik> spec is done?

Do the base review after the extensions work is done.

    Patrik> If that is done after IMAPEXT work is done, do you see a
    Patrik> problem with delaying that review?

No.

    Patrik> If that is done in parallell, do you think other people
    Patrik> will work with base spec than IMAPEXT issues?

I think everyone working on extensions will also work on the base
review. The outcome of the extensions work will affect things when
we review the base, so the extensions group really has to wrap up first.
Also, if we do both at once, our time will become too fragmented to
do a good job on either one.

Also, if a review of 2060 *is* necessary, I think the IMAP
development community is capable of deciding the time and
place for that to happen. Having third-parties dictate the
need for a base review is out of line (even if some of them
are area directors).

--lyndon

Date: Mon, 07 Feb 2000 15:09:18 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Sender: [email-masked]

--On 2000-02-07 06.59 -0700, Lyndon Nerenberg <[email-masked]>
wrote:

> I am completely opposed to incorporating a base spec review into
> the working group charter. We need to get the things identified
> in the original charter dealt with -- this year. Adding a base spec
> review by fiat like this is completely unacceptable.

How, when, where would you suggest a review of the base spec is done?

If that is done after IMAPEXT work is done, do you see a problem with
delaying that review?

If that is done in parallell, do you think other people will work with base
spec than IMAPEXT issues?

   paf

From: Lyndon Nerenberg <[email-masked]>
to: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 07 Feb 2000 06:59:52 -0700
Sender: [email-masked]

I am completely opposed to incorporating a base spec review into
the working group charter. We need to get the things identified
in the original charter dealt with -- this year. Adding a base spec
review by fiat like this is completely unacceptable.

--lyndon

Date: Sun, 06 Feb 2000 21:55:12 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On 2000-02-06 12.16 -0800, "Paul Hoffman / IMC" <[email-masked]> wrote:

> This seems like a straightforward layer 8 question. If the IESG wants it
> that way, let's do it that way. If we stumble and scrape our knees on the
> way, we can blame them. :-)

Writing documents about "existing" protocols like the IMAP base protocol
will always be painful.

The point here is though that IESG belive (tell us if we are wrong):

- It is about time it is done
- People that have the knowledge and can do it, will be in this wg
  anyways

...and yes, I am the one which have to buy band-aid...

Whether it is an update of the old one (which Pete said he had talked with
Keith about) or a new document, that doesn't matter for me. You know better
than me what gives the most bang for the buck.

It is not the case that IESG _tell_ you to do it (at this point in time
;-). We just belive it would be the cheapest way of going forward.

      paf

Date: Sun, 06 Feb 2000 12:16:09 -0800
To: IMAP Extensions <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

This seems like a straightforward layer 8 question. If the IESG wants it 
that way, let's do it that way. If we stumble and scrape our knees on the 
way, we can blame them. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 6 Feb 2000 14:05:18 -0600
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT Chartering
Sender: [email-masked]

I forward the following message to the working group (bcc'ing the 
Keith, Patrik, and Ned) unedited. My only comment is that Keith 
originally brought to me privately the suggestion that we "add 
another milestone to the charter to write an informational rfc" on 
"interoperability problems resulting from ambiguities in the specs - 
and then to get consensus on an approach to solving those problems, 
before working on actual extensions". I objected to Keith (again, 
privately) on the grounds that we wanted to limit the scope of this 
WG to extensions only. Below is Patrik's message. I will make no 
further comments to the ADs on this topic until I hear from the list 
on this. Please make comments to the list. (Keith, Patrik, and Ned: 
Please see [email-masked] if you want to read the comments for 
yourselves.)

--- begin forwarded text

Return-Path: <[email-masked]>
Date: Sun, 06 Feb 2000 20:41:33 +0100
From: Patrik Fältström <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: IMAPEXT progress?

--On 2000-02-03 16.41 -0600, Pete Resnick <[email-masked]> wrote:

>  Anything going on with regard to the chartering of IMAPEXT?

After discussing this for some time among some IESG and IAB members, we
have agreed that this is a go _IF_ you add to the charter a refreshment of
the base IMAP spec.

Yes, we know you don't like it, and we don't normally do it this way. I.e.
a wg working with extensions should not also do the base spec. It is also
the case that we normally (as you know personally ;-) want people to first
do the boring stuff, and then get to the dessert.

But, in the case of IMAP, we feel that many people work really hard, and
the same people would work on the extensions _and_ the base spec. Because
of this, we don't see any need for two working groups.

Let us know what you feel about it.

    Regards, Patrik

--- end forwarded text
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Fri, 18 Feb 2000 20:59:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
To: Tony Hansen <[email-masked]>
cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 18 Feb 2000 23:49:13 -0500, Tony Hansen wrote:
> Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1,
> but was. Since we've started down the path of using "revX", shouldn't it
> be continued?

There were incompatible changes between RFC 1730 and RFC 2060.  Specifically,
poorly-designed RFC 1730 features relating to partial fetching were deleted
from the IMAP specification, and much better features added in RFC 2060.

A vendor insisted that it had to be possible to distinguish between RFC 1730
and RFC 2060 servers.  It's a long story, but my arm was severely twisted to
create "IMAP4rev1" (what an ugly name!).  No, it was not the Evil Empire.

Of course, nobody actually depended upon the broken features of RFC 1730 (if
you tried to implement them, you'd find out why...) and everybody thinks that
RFC 2060 is the one true IMAP (as they should).  But we're apparently stuck
with that "rev1" suffix forever.

This is not the case with the new draft.  The vast majority of the draft
consists of clarifications of what is in RFC 2060.  There's a small handful of
new status codes.  Nevertheless, there's no reason for a strict RFC 2060
implementation to have any problem with an implementation that supports the
new draft or vice versa.

Date: Fri, 18 Feb 2000 23:49:13 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
Sender: [email-masked]

Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1,
but was. Since we've started down the path of using "revX", shouldn't it
be continued?

	Tony Hansen
	[email-masked]

Mark Crispin wrote:
> 
> I would like to make a last call on the IMAPV document, which is
> essentially a bugfix update to RFC 2060.  Please read and review it,
> since I would like to submit it as an RFC as the new standards-track
> bas IMAP specification.
> 
> ---------- Forwarded message ----------
> Subject: I-D ACTION:draft-crispin-imapv-09.txt
> 
> 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-09.txt

Date: Fri, 18 Feb 2000 18:33:32 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

I would like to make a last call on the IMAPV document, which is
essentially a bugfix update to RFC 2060.  Please read and review it, since
I would like to submit it as an RFC as the new standards-track bas IMAP
specification.

---------- Forwarded message ----------
Date: Thu, 17 Feb 2000 06:27:25 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapv-09.txt

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-09.txt
	Pages		: 93
	Date		: 16-Feb-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]).
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes; checking for new messages; permanently removing messages;
setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
searching; and selective fetching of message attributes, texts, and
numbers.  These numbers are either message sequence numbers or unique
identifiers.
IMAP4rev1 supports a single server.  A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols.  In the course of the evolution of
IMAP4rev1, some aspects in the earlier protocol have become obsolete.
Obsolete commands, responses, and data formats which an IMAP4rev1
implementation can encounter when used with an earlier implementation
are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT].  A full
discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapv-09.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-09.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-09.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
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imapv-09.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Wed, 16 Feb 2000 12:23:11 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Pete Resnick <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

For what it's worth, I had not planned to go to Adelaide.  I made multiple
inquiries to see if anything IMAP-relevant would go on there, with no answer.
Even if I make arrangements to do, I can not get to Adelaide until Tuesday at
the swiftest due to other commitments.

I don't think that there is a controversy.  I haven't heard of anybody in IMAP
or IMAPEXT who wants to charter IMAPEXT with base spec work on its agenda.
IESG should be told that the unanimous opinion of the IMAP community is a
rejection of this notion.

On Wed, 16 Feb 2000 11:22:18 -0600, Pete Resnick wrote:
> Unless this round of discussion on the list has convinced the people
> in question, I think there has been enough indication of controversy
> that a WG/BOF meeting be scheduled at Adelaide at which time we
> should work this out. Members of the IAB/IESG who think the base spec
> work item should be added to the charter ought to be present.

Date: Wed, 16 Feb 2000 11:22:18 -0600
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: IMAPEXT Chartering
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

I promised not to make a comment on this topic, but it seems that 
most folks who are going to chime in have done so. So, first with my 
chairman hat off:

On 2/7/00 at 3:09 PM +0100, Patrik Fältström wrote:

>How, when, where would you suggest a review of the base spec is done?

The base spec is being worked on right now and may be about to go to 
last call. It can get review during this time, and if there are folks 
who think that progressing it should be held up until an 
informational document is produced, they can hold up this rev of the 
base spec. If a working group is required to get that job done, one 
can be formed. This can be done independently and in parallel with 
IMAPEXT.

>If that is done in parallell, do you think other people will work 
>with base spec than IMAPEXT issues?

There will clearly be a huge intersection of people. That's 
irrelevant. Combining the two activities almost guarantees leakage 
between the two topics. I can hear it now: "Oh, that problem with the 
base spec can be solved with an extension; let's just add that to our 
charter." Or even better, "That extension will work if we make one 
little change to the base spec; let's do that during the base spec 
review." This has disaster written all over it. Keeping the 
activities separate forces the extensions to be clean and independent 
of base spec changes and forces base spec cleanups (if needed) to not 
be kludges.

Now, with my chairman hat on:

Unless this round of discussion on the list has convinced the people 
in question, I think there has been enough indication of controversy 
that a WG/BOF meeting be scheduled at Adelaide at which time we 
should work this out. Members of the IAB/IESG who think the base spec 
work item should be added to the charter ought to be present.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 16 Feb 2000 10:26:59 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On Tuesday, February 15, 2000 7:20 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> I agree.  But I dread making a last call.  The silence in the past several
> months (years, actually) of various imapv drafts frightens me.  I just
> know that there won't be any feedback until there's a last call, then
> suddenly will come vehement demands for massive rewrites or new text.
>
> OK, I am sending out draft 09 today.  The only changes from 08 are
> pointing out how % works with LSUB and clarify the "don't use STATUS on
> the selected mailbox rule."
>
> PS: I didn't call it "imapv", the I-D editor did for reasons which are
> still unclear to me...ours is not to question why, ours is but to do or...

Well given the negative response on this list to the idea of revising the 
base-spec as a whole I don't see how there could be major objections to 
"imapv" and resulting rewrites of "imapv". So personally I think you should 
last call it.

-- 
Cyrus

Date: Tue, 15 Feb 2000 19:20:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Tue, 15 Feb 2000 14:16:00 -0500, Cyrus Daboo wrote:
> Agreed. But should we not pursue making the current 'imapv' draft an RFC?

I agree.  But I dread making a last call.  The silence in the past several
months (years, actually) of various imapv drafts frightens me.  I just know
that there won't be any feedback until there's a last call, then suddenly will
come vehement demands for massive rewrites or new text.

OK, I am sending out draft 09 today.  The only changes from 08 are pointing
out how % works with LSUB and clarify the "don't use STATUS on the selected
mailbox rule."

PS: I didn't call it "imapv", the I-D editor did for reasons which are still
unclear to me...ours is not to question why, ours is but to do or...

Date: Tue, 15 Feb 2000 14:16:00 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On Tuesday, February 15, 2000 10:48 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> For what it's worth, I agree with all of the comments which oppose a
> refresh of the base IMAP spec, for the reasons given.
>
> If people have a problem with reading ABNF and want to implement from
> examples, then the obvious solution is to flush all the examples from the
> base spec.  ;-)

Agreed. But should we not pursue making the current 'imapv' draft an RFC? 
There are quite a few corrections (minor) and some additions (also minor) 
making a total of 61 changes in the -08 draft that would be nice to see as 
a 'proper' RFC, updating 2060. I've come across some people that are 
reluctant to make these changes in their products because they are not in a 
'proper' RFC.

-- 
Cyrus

Date: Tue, 15 Feb 2000 10:48:14 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering
To: Steve Hole <[email-masked]>
cc: Pete Resnick <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

For what it's worth, I agree with all of the comments which oppose a refresh
of the base IMAP spec, for the reasons given.

If people have a problem with reading ABNF and want to implement from
examples, then the obvious solution is to flush all the examples from the base
spec.  ;-)

From: Steve Hole <[email-masked]>
Date: Mon, 14 Feb 2000 22:10:28 -0700
To: Pete Resnick <[email-masked]>
Subject: Re: IMAPEXT Chartering
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Sun, 6 Feb 2000 14:05:18 -0600 Pete Resnick <[email-masked]> 
wrote:

> Return-Path: <[email-masked]>
> Date: Sun, 06 Feb 2000 20:41:33 +0100
> From: Patrik Fältström <[email-masked]>
> To: Pete Resnick <[email-masked]>
> cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>
> Subject: Re: IMAPEXT progress?
> 
> --On 2000-02-03 16.41 -0600, Pete Resnick <[email-masked]> wrote:
> 
> >  Anything going on with regard to the chartering of IMAPEXT?
> 
> After discussing this for some time among some IESG and IAB members, we
> have agreed that this is a go _IF_ you add to the charter a refreshment of
> the base IMAP spec.
> 
> Yes, we know you don't like it, and we don't normally do it this way. I.e.
> a wg working with extensions should not also do the base spec. It is also
> the case that we normally (as you know personally ;-) want people to first
> do the boring stuff, and then get to the dessert.
> 
> But, in the case of IMAP, we feel that many people work really hard, and
> the same people would work on the extensions _and_ the base spec. Because
> of this, we don't see any need for two working groups.

I cannot believe that this is a good idea.   (1) it implies that there is 
a lot of work to do on the base specification, which is not true, and (2) 
it will delay the extension work substantially.

I suspect that I know where much of this request originated.  The bottom 
line is that, with the exception of the NAMESPACE extension, 
interoperability is pretty decent these days.    Some people still have a 
problem reading ABNF and want to implement from the examples, but that is 
not a problem for IMAP in particular.   Frankly, we seem to have a lot 
more problem with MIME and S/MIME interoperability than we do with IMAP.

There are some things that can be done to improve the capability and 
useability of IMAP.    Most of these can be addressed as extensions.   I 
really see no reason to take on this work.

Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Tue, 15 Feb 2000 12:00:31 +0000
To: [email-masked], [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd)
Sender: [email-masked]

The formal syntax used in draft-crispin-imap-multiappend-00.txt seems to
have fallen between two stools, it follows neither RFC2234 nor RFC2060.

Assuming that the syntax is supposed to conform to RFC2234 (as does
draft-crispin-imapv-08.txt) then replace SPACE with SP and _ with -
throughout

>
>Modification to IMAP4rev1 Base Protocol Formal Syntax
>
>   append          = "APPEND" SPACE mailbox 1*append_message
>
>   append-message  = [SPACE flag_list] [SPACE date_time] SPACE literal
>
>
>MULTIAPPEND Interaction with UIDPLUS Extension
>
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>
>   resp-code-apnd  = "APPENDUID" SPACE nz_number 1*(SPACE uniqueid)
>

Becomes

Modification to IMAP4rev1 Base Protocol Formal Syntax

   append          = "APPEND" SP mailbox 1*append-message

   append-message  = [SP flag-list] [SP date-time] SP literal

MULTIAPPEND Interaction with UIDPLUS Extension

   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
   "resp-code-apnd" rule modified as follows:

   resp-code-apnd  = "APPENDUID" SP nz-number 1*(SP uniqueid)

On the other hand if it is not intended to conform to RFC2234 but to
follow RFC2060 then replace = with ::= and - with _ throughout.

Regards 

-- 
Paul Overell                                             T U R N P I K E

Date: Mon, 14 Feb 2000 08:21:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
cc: IMAP Interest List <[email-masked]>
Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

As promised, here is the specification for MULTIAPPEND.  Preliminary
testing of the c-client implementation shows that it is a major winner,
and much less kludgy than streaming appends!

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

---------- Forwarded message ----------
Date: Mon, 14 Feb 2000 06:44:26 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND      
                          EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imap-multiappend-00.txt
	Pages		: 5
	Date		: 11-Feb-00
	
This document describes the multiappending extension to the [IMAP]
protocol.  This extension provides substantial performance
improvements for IMAP clients which upload multiple messages at a
time to a mailbox on the server.
A server which supports this extension indicates this with a
capability name of 'MULTIAPPEND'.

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

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

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

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

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

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

--NextPart
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Tue, 8 Feb 2000 11:45:13 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2 forwarded messages...
Organization: Networks & Distributed Computing
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--16819560-1488665461-950039113=:29569
Content-Type: TEXT/PLAIN; charset=US-ASCII

I've re-posted the SORT and THREAD drafts, since the old ones are
expiring.  There are no changes in either other than the obvious
editorial ones.

Since it's been 6 months, I would like to call a "last call" for the SORT
draft to be submitted to the IESG for publication as an Informational or
Experimental RFC.  Once that has been done, I will reconstitute the SORT
draft as a working document of IMAPEXT (called SORT+ or SORTrev1 or
whatever) and then we can talk about the addressions to go into it.

I would like group input on what to do about THREAD.  I suggest that we
should just go and publish THREAD as a Proposed Standard, on the grounds
that THREAD can be extended arbitrarily (ala SASL) and, as in SASL, it
makes no sense to block advancement of the framework just because some of
the algorithms aren't fully specified yet.  In any case, I agree that we
have add the missing algorithms (for In-Reply-To and References threading)
prior to it getting beyond Proposed, either in the THREAD document or as
auxillary documents.

Bottom line on my recommendations:

1) Push SORT to informational/experimental RFC now.
2) Start standards-track SORTxxx draft, with SORT RFC as its basis.
3) Push THREAD to proposed standard RFC now, even though
    THREAD=ORDEREDSUBJECT is the only algorithm defined as yet.
4) Start THREAD=INREPLYTO and THREAD=REFERENCES draft.

The documents in (2) and (4) would be IMAPEXT WG documents.

--16819560-1488665461-950039113=:29569
Content-Type: MULTIPART/Digest; BOUNDARY="16819560-719432153-950039113=:29569"
Content-ID: <[email-masked]>
Content-Description: Digest of 2 messages

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--16819560-719432153-950039113=:29569
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <[email-masked]>
Content-Description: I-D ACTION:draft-crispin-imapext-sort-01.txt (fwd)

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapext-sort-01.txt
Date: Tue, 08 Feb 2000 06:31:30 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-sort-01.txt
	Pages		: 9
	Date		: 07-Feb-00
	
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-crispin-imapext-sort-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapext-sort-01.txt

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

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

--OtherAccess--

--NextPart--

--16819560-719432153-950039113=:29569
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <[email-masked]>
Content-Description: I-D ACTION:draft-crispin-imapext-thread-01.txt (fwd)

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imapext-thread-01.txt
Date: Tue, 08 Feb 2000 06:32:52 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-thread-01.txt
	Pages		: 7
	Date		: 07-Feb-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-crispin-imapext-thread-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-crispin-imapext-thread-01.txt

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

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

--OtherAccess--

--NextPart--

--16819560-719432153-950039113=:29569--
--16819560-1488665461-950039113=:29569--

Date: Mon, 7 Feb 2000 16:50:36 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAPEXT Chartering 
To: Mike Gahrns <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, IMAP Extensions <[email-masked]>
Sender: [email-masked]

I agree completely with Mike Gahrns' comments.

It is not clear to me that WG action is required on the base spec.  We may
want to draw up a list of which points from Barry's document should go in the
base spec, but those should be held to clarifications (or possibly
prohibitions).

The only extension which *may* belong in the base spec is STARTTLS.  None of
the other extensions are of such vital importance that a server must have it
or be considered broken.  At least one of the extensions (NAMESPACE) has been
known to create problems with certain (we all know which) clients.

From: "Mike Gahrns" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: "IMAP Extensions" <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 7 Feb 2000 16:27:10 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BF7188.2EC42280
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: IMAPEXT CharteringI agree with Lyndon and others to do the review of =
the base spec after any extensions are done.  (Assuming that a review of =
the base spec needs to be in the IMAPEXT charter, which I don't think is =
the case).

I also wonder if the perceived need of doing a review of the base spec =
is based upon the state of IMAP interoperability a fews ago.

My personal opinion is that IMAP interoperability is now good.  =
Admittedly there are some implementations that may not do things in the =
most efficient manner, and may not take full advantage of the protocol, =
but I think we are at a point now where interop between various vendor's =
IMAP client's and servers is decent.  I think the results from the =
various IMC mail connects bear this out.  The group definitely did iron =
out some kink in some implementations as a result of these events, and =
the group also worked quite hard on the "implementor's guide" that barry =
leiba put together.  As a result, IMAP interop today is probably better =
than some people may perceive it to be.

------=_NextPart_000_0008_01BF7188.2EC42280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: IMAPEXT Chartering</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I agree with Lyndon and others to do =
the review of=20
the base spec after any extensions are done.&nbsp; (Assuming that a =
review of=20
the base spec needs to be in the IMAPEXT charter, which I don't think is =
the=20
case).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I also wonder if the perceived need of =
doing a=20
review of the base spec is based upon the state of IMAP interoperability =
a fews=20
ago.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My&nbsp;personal opinion is that IMAP=20
interoperability is now&nbsp;good.&nbsp; Admittedly there are some=20
implementations that may not do things in the most efficient manner, and =
may not=20
take full advantage of the protocol, but I think we are at a point now =
where=20
interop between various vendor's IMAP client's and servers =
is&nbsp;decent.&nbsp;=20
I think the results from the various IMC mail connects&nbsp;bear this =
out.&nbsp;=20
The group definitely did iron out some kink in some =
implementations&nbsp;as a=20
result of these events, and the group also worked quite hard on the=20
"implementor's guide" that barry leiba put together.&nbsp; As a result, =
IMAP=20
interop today is probably better than some people may perceive it to=20
be.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01BF7188.2EC42280--

From: Lyndon Nerenberg <[email-masked]>
To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 07 Feb 2000 08:11:11 -0700
Sender: [email-masked]

>>>>> "Patrik" == Patrik Fältström <[email-masked]> writes:

    Patrik> How, when, where would you suggest a review of the base
    Patrik> spec is done?

Do the base review after the extensions work is done.

    Patrik> If that is done after IMAPEXT work is done, do you see a
    Patrik> problem with delaying that review?

No.

    Patrik> If that is done in parallell, do you think other people
    Patrik> will work with base spec than IMAPEXT issues?

I think everyone working on extensions will also work on the base
review. The outcome of the extensions work will affect things when
we review the base, so the extensions group really has to wrap up first.
Also, if we do both at once, our time will become too fragmented to
do a good job on either one.

Also, if a review of 2060 *is* necessary, I think the IMAP
development community is capable of deciding the time and
place for that to happen. Having third-parties dictate the
need for a base review is out of line (even if some of them
are area directors).

--lyndon

Date: Mon, 07 Feb 2000 15:09:18 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Sender: [email-masked]

--On 2000-02-07 06.59 -0700, Lyndon Nerenberg <[email-masked]>
wrote:

> I am completely opposed to incorporating a base spec review into
> the working group charter. We need to get the things identified
> in the original charter dealt with -- this year. Adding a base spec
> review by fiat like this is completely unacceptable.

How, when, where would you suggest a review of the base spec is done?

If that is done after IMAPEXT work is done, do you see a problem with
delaying that review?

If that is done in parallell, do you think other people will work with base
spec than IMAPEXT issues?

   paf

From: Lyndon Nerenberg <[email-masked]>
to: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering 
Date: Mon, 07 Feb 2000 06:59:52 -0700
Sender: [email-masked]

I am completely opposed to incorporating a base spec review into
the working group charter. We need to get the things identified
in the original charter dealt with -- this year. Adding a base spec
review by fiat like this is completely unacceptable.

--lyndon

Date: Sun, 06 Feb 2000 21:55:12 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

--On 2000-02-06 12.16 -0800, "Paul Hoffman / IMC" <[email-masked]> wrote:

> This seems like a straightforward layer 8 question. If the IESG wants it
> that way, let's do it that way. If we stumble and scrape our knees on the
> way, we can blame them. :-)

Writing documents about "existing" protocols like the IMAP base protocol
will always be painful.

The point here is though that IESG belive (tell us if we are wrong):

- It is about time it is done
- People that have the knowledge and can do it, will be in this wg
  anyways

...and yes, I am the one which have to buy band-aid...

Whether it is an update of the old one (which Pete said he had talked with
Keith about) or a new document, that doesn't matter for me. You know better
than me what gives the most bang for the buck.

It is not the case that IESG _tell_ you to do it (at this point in time
;-). We just belive it would be the cheapest way of going forward.

      paf

Date: Sun, 06 Feb 2000 12:16:09 -0800
To: IMAP Extensions <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IMAPEXT Chartering
Sender: [email-masked]

This seems like a straightforward layer 8 question. If the IESG wants it 
that way, let's do it that way. If we stumble and scrape our knees on the 
way, we can blame them. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 6 Feb 2000 14:05:18 -0600
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT Chartering
Sender: [email-masked]

I forward the following message to the working group (bcc'ing the 
Keith, Patrik, and Ned) unedited. My only comment is that Keith 
originally brought to me privately the suggestion that we "add 
another milestone to the charter to write an informational rfc" on 
"interoperability problems resulting from ambiguities in the specs - 
and then to get consensus on an approach to solving those problems, 
before working on actual extensions". I objected to Keith (again, 
privately) on the grounds that we wanted to limit the scope of this 
WG to extensions only. Below is Patrik's message. I will make no 
further comments to the ADs on this topic until I hear from the list 
on this. Please make comments to the list. (Keith, Patrik, and Ned: 
Please see [email-masked] if you want to read the comments for 
yourselves.)

--- begin forwarded text

Return-Path: <[email-masked]>
Date: Sun, 06 Feb 2000 20:41:33 +0100
From: Patrik Fältström <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: IMAPEXT progress?

--On 2000-02-03 16.41 -0600, Pete Resnick <[email-masked]> wrote:

>  Anything going on with regard to the chartering of IMAPEXT?

After discussing this for some time among some IESG and IAB members, we
have agreed that this is a go _IF_ you add to the charter a refreshment of
the base IMAP spec.

Yes, we know you don't like it, and we don't normally do it this way. I.e.
a wg working with extensions should not also do the base spec. It is also
the case that we normally (as you know personally ;-) want people to first
do the boring stuff, and then get to the dessert.

But, in the case of IMAP, we feel that many people work really hard, and
the same people would work on the extensions _and_ the base spec. Because
of this, we don't see any need for two working groups.

Let us know what you feel about it.

    Regards, Patrik

--- end forwarded text
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102