Subject: Re: New ANNOTATEMORE draft
From: Ken Murchison <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Fri, 30 May 2003 14:12:47 -0400
List-Id: <ietf-imapext.imc.org>

Cyrus Daboo wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>     Title        : IMAP ANNOTATEMORE Extension
>     Author(s)    : C. Daboo
>     Filename    : draft-daboo-imap-annotatemore-03.txt
>     Pages        : 17
>     Date        : 2003-5-20

 From section 7:

"If a client attempts to store or retrieve a shared annotation on a 
READ-ONLY mailbox, the server MUST respond with a NO response."

Is there a reason why I shouldn't be able to fetch a shared annotation 
on a READ-ONLY mailbox?

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

Date: Wed, 21 May 2003 11:43:17 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: New ANNOTATEMORE draft
Sender: [email-masked]

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-03.txt
	Pages		: 17
	Date		: 2003-5-20
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  This document describes two 'profiles' for mailbox and
server metadata.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-daboo-imap-annotatemore-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-daboo-imap-annotatemore-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.

-- 
Cyrus Daboo

Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-07.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 21 May 2003 15:34:52 +0300
Sender: [email-masked]

>    In some cases, servers may be able to offer annotations on some
>    mailboxes and not others.  For mailboxes that cannot have
>    annotations associated with them, the server MUST return an
>    "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT
>    or EXAMINE command for that mailbox.  Clients MUST NOT attempt to
>    fetch or store annotations on any messages in a mailbox for which
>    the "ANNOTATESIZE" response was zero.

What if I want read-only annotation support? I think ANNOTATESIZE 0
should mean that client must not attept to store annotations, but it may
try fetching shared annotations.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-07.txt
Date: Wed, 21 May 2003 08:10:40 -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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-07.txt
	Pages		: 22
	Date		: 2003-5-20
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-annotate-07.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-annotate-07.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-annotate-07.txt

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

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

--OtherAccess--

--NextPart--

From: Michael Fair <[email-masked]>
Organization: DaClubhouse
To: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: Foreknowledge  versus pipelines
Date: Tue, 20 May 2003 19:07:58 -0700
Sender: [email-masked]

On Tuesday 20 May 2003 01:39 pm, Timo Sirainen wrote:
> On Tue, 2003-05-20 at 22:22, Michael Fair wrote:
> > Could we achieve the same result by having the server dump the
> > queue and then /dev/null the rest of the incoming queue data
> > and then once that's finished return a "NO" to the client
> > citing the error?
>
> Currently my server just disconnects the client if it tries to use too
> large literal+ size. I don't think it's a good idea to allow clients to
> say "hey, I'll send you 2 gigabytes of data, start reading" especially
> before logging in.

What's to stop a client from doing that now?
S: * Hello Welcome to IMAP
C: 1 a
C: 2 a
C: 3 a
.....  Repeat 2G worth .....

The result is the same - it's just less explicit about its intentions.

> How about specifying a limit for which you can use literal+? So that if
> you send less data than eg. 8192 bytes, you can safely send it, but for
> anything more you'd have to use regular literals which server can
> reject.

I'll have to read up on literal+ to understand what it does and how it behaves 
before I can really comment.  If we are going to refuse a client for too much 
data before they start sending it, then I think we should explicitly tell 
them that it's clear to send somehow.  I'm thinking a client must wait till 
it receives a response from the server which can be "+", "NO" or "BAD".

If "+" the client can send the data.  Once the number of octects specified by 
the client for the CQUEUE is reached, the buffer closes and if the buffer 
does not end in a \r\n it is a syntax error and is responded with "BAD" 
immediately.  No further data is read by the server until the CQUEUE is
finished or until a command in the queue that needs more input is reached.

> > If we fix the octet counts so that server announces a max octet
> > buffer which cannot be exceeded, and the client announces how
> > much data it is submitting, the last two octets of which must
> > be \r\n (the end of a command), would that satisfy the concerns
> > that you have over this causing problems for generic usage?
>
> No, I'm thinking there could be some more subtle problems when some of
> the commands in the group changes state in some way. My server currently
> trashes all buffered input after logging in since the client's socket is
> transferred to another process, but maybe I should fix that since it's
> not fully IMAP compliant..

The full intent of this is to allow the client to optimistically "guess" a 
valid command path to go from HELLO to AUTHENTICATED.  I expect clients might 
want to cache the command chain that worked and replay it whenever they log 
in for that account.

Each command either succeeds, or the whole process stops.  Each command is 
executed in order.  This way the client progresses through the various states 
without stopping to check the environment (unless the chain fails of course).

So this leads me to:

S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (111)
S: +
C: 3 VHOST (fqdn.example.com)
C: 4 LANGUAGE (new_lang)
C: 5 STARTTLS
C: 6 AUTHENTICATE PLAIN
C: 7 SELECT INBOX
... Rest as before but selecting the INBOX at the very end of the chain ...

And for failures:
S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (9999)
S: 2 NO Too much data

S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (11)
S: +
C: 3 VHOST (fqdn.example.com)
S: 2 BAD Buffer does not end on a newline
... Server then should discard everything up to the next \r\n lest 
    it choke on bad input ...

> > > > As with the GROUP proposal, as bonus points, there would
> > > > be an optional "TRANSACTION" parameter which would have
<snip>
> - etc.

Until the rest of the command has been settled on I'm removing this from the
list unless someone else would like to take a stab at clearly defining the 
semantics.  If someone does want to take it on, for the most part, it should 
be sufficient to follow SQL database semantics for this in regards to 
simoultaneous access - CQUEUE with TRANSACTION could lock all writes to the 
mail store until it completed (most likely responding with "NO Transaction in 
progress" for any write operations until the QUEUE completed.  If a command 
should fail, then the mail store should be message data and state identical 
to what it was before, and the session should be in whatever state it was in 
prior to the CQUEUE command.  

A more advanced server could parse through the command structure and build a 
list of object locks it would need prior to starting, would then lock those 
objects (or fail if it couldn't obtain such locks), and execute the commands.  
Any other client wanting to operate on other non-locked objects could be 
allowed to do so, attempting to write to a locked object should fail 
instantly to notify the client that the data is potentially about to change 
and it should fetch an update.  Reading locked objects might be a blocking 
operation until the transaction completes, or might be refused pending 
transaction completion.  I don't know exactly what all the details for the 
most useful operation behaviors would be - or even why it might be useful, so 
until there is a clearer use case and understanding of the mail store and 
session states as transactional creatures I'll withdraw it from the table.

-- Michael --

Subject: Re: Foreknowledge  versus pipelines
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 20 May 2003 23:39:00 +0300
Sender: [email-masked]

On Tue, 2003-05-20 at 22:22, Michael Fair wrote:
> Could we achieve the same result by having the server dump the 
> queue and then /dev/null the rest of the incoming queue data
> and then once that's finished return a "NO" to the client
> citing the error?

Currently my server just disconnects the client if it tries to use too
large literal+ size. I don't think it's a good idea to allow clients to
say "hey, I'll send you 2 gigabytes of data, start reading" especially
before logging in.

How about specifying a limit for which you can use literal+? So that if
you send less data than eg. 8192 bytes, you can safely send it, but for
anything more you'd have to use regular literals which server can
reject.

So:

1 cgroup {40+}
2 capability
3 starttls
4 authenticate plain
..

10 cgroup {1000000}
10 NO Too much data

> If we fix the octet counts so that server announces a max octet
> buffer which cannot be exceeded, and the client announces how
> much data it is submitting, the last two octets of which must
> be \r\n (the end of a command), would that satisfy the concerns
> that you have over this causing problems for generic usage?

No, I'm thinking there could be some more subtle problems when some of
the commands in the group changes state in some way. My server currently
trashes all buffered input after logging in since the client's socket is
transferred to another process, but maybe I should fix that since it's
not fully IMAP compliant..

> > > As with the GROUP proposal, as bonus points, there would 
> > > be an optional "TRANSACTION" parameter which would have
> > > a server revert to the same state prior to executing 
> > > the CQUEUE chain.
> > 
> > No, even if server used a database capable of transactions for storing
> > messages this would get complex.
> 
> I should have been clearer: TRANSACTION is an optional server
> implementation choice.  It is an addon to CQUEUE not part of it.
> It was never intended that any servers had to implement it.
> The only other option would be to omit the possibility entirely
> which I felt would be somewhat of an oversight.

If you specify it, you'll have to specify exactly what it does. "revert
to original state" isn't very exact. For example:

- Does any other session see the changes before transaction is complete?
(No, or it breaks really badly)

- Client must be able to revert it's own understanding of the server
state as well.

- What happens if there's external updates while processing the
transaction? Should server just not announce those (could be difficult),
or how would client know what the original state looked like? For
example you do EXPUNGE and the next command fails, server reverts the
EXPUNGE but not the few pending EXPUNGEs that weren't yet announced to
client. Does client now have any idea what sequence number is what?

- etc.

From: "Michael Fair" <[email-masked]>
To: "Timo Sirainen" <[email-masked]>, <[email-masked]>
Subject: Re: Foreknowledge  versus pipelines
Date: Tue, 20 May 2003 12:22:30 -0700
Organization: DaClubhouse
Sender: [email-masked]

> 
> On Mon, 2003-05-19 at 02:28, Michael Fair wrote:
> > S: * Hello Welcome to the IMAP server
> > S: * CAPABILITY CQUEUE STARTTLS VHOST .......
> > C: tag1 CQUEUE (4)
> > C: tag2 VHOST (fqdn.example.com)
> > C: tag3 LANGUAGE (new_lang)
> > C: tag4 STARTTLS
> > C: tag5 AUTHENTICATE PLAIN
> 
> This isn't too easy to implement. At the very least server should be
> able to abort the whole queue if it doesn't like it for some reason, for
> example because it thinks it has too much data in it.

I think that would be a fine idea.  Part of the reason I put
(4) in the CQUEUE command was to give the server the opportunity
to allocate an array of strings.  I then figured it would fill
the array and then execute the commands.  Perhaps this wasn't
the right approach.

What if the server CAPABILITY response provided a CQUEUE maxoctets 
parameter which will gave the maximum number of octets including 
the tags and \r\n that the server can store.
So the CAPABILITY response might read: CQUEUE (8192)

If that's the case, then perhaps the initial parameter to CQUEUE 
the client submits should be the number of octets the client will 
be submitting (including \r\n and tags).  So instead of CQUEUE (4)
which was 4 commands it would be "tag1 CQUEUE (97)" Which would be
everything from "tag2" to the "\r\n" of AUTHENTICATE (assuming I 
counted that right).  If any characters are multibyte characters
then those characters count as multiple octets.

If the server should find that there is too much data, the server
should dump the queue, /dev/null the rest of the incoming queue 
data (which is now countable by the number of octets) and then 
respond with "NO" giving an appropriate reason.

> Still .. it would require that server reads the data into buffer before
> processing any of it. And could there be literals in queue? That would
> mean that server has to actually parse all the commands before executing
> them. That could get tricky.
>
> Maybe a bit easier version would be to send the commands inside a
> literal so server can just read it into buffer, and it can immediately
> tell the client if there's just too much data in it (literal+ shouldn't
> be allowed with it).

I'm afraid I'm not too familiar with many IMAP commands.  The 
intent was that only single line commands could be queued.  
And the newlines would be used as command separators.  The
tags were needed to identify the individual commands in the queue
and would be treated as if they were executed without the CQUEUE
command so should be globally unique within the session.
Commands that required more than one line would be processed 
in turn and would fetch any extra lines at the time of execution.
The server would delay parsing the command until it was time to 
execute it.

If literal+ is an extra long one-liner, then I think if we used
the octet count strategy from above there'd be no reason to keep
it excluded from the list of valid commands.

I don't know that the server "immediately" telling the client
there's too much data is necessary.  It's also very probable
given how I was thinking this command would be used, that the 
client isn't paying attention to server responses at the time 
they are filling the queue.  

Could we achieve the same result by having the server dump the 
queue and then /dev/null the rest of the incoming queue data
and then once that's finished return a "NO" to the client
citing the error?

I'm picturing that the client is going to be in two modes
when it uses this command.  Mode 1, is to stuff a bunch of
commands in the queue, and then mode 2 is to get the results
of each command and interact with any conversations it has
to have to process them.

If we use the byte counters I suggested above then CQUEUE
could treat that many following bytes as literal data stuffing
it in a single buffer and then reading from it.

> Still, I'm not sure if this is a good idea. As limited in above example
> it would work, but as a more generic feature it would just cause
> problems.

The primary motivation for this was to reduce round trips with
the server during the log in process when the overall consensus 
is that many smaller commands is better than a generic big one.
The discussion saw parallels to the MULTIAPPEND discussion
(which I wasn't around for) and it seemed that an alternative
that might have worked there could also work here.

I had already worked on several commands that were very similar
in nature to this proposal and figured that there was probably
no escaping it.  So the only question was is this new command
only valid in the non-AUTHENTICATED state, or is it something
that could be genericly useful?  I'd tend towards the more
generic mostly because I'm just bent that way, but if this only
ended up to server the log in process it will have met the 
original design goals I had in mind.

If we fix the octet counts so that server announces a max octet
buffer which cannot be exceeded, and the client announces how
much data it is submitting, the last two octets of which must
be \r\n (the end of a command), would that satisfy the concerns
that you have over this causing problems for generic usage?

> > As with the GROUP proposal, as bonus points, there would 
> > be an optional "TRANSACTION" parameter which would have
> > a server revert to the same state prior to executing 
> > the CQUEUE chain.
> 
> No, even if server used a database capable of transactions for storing
> messages this would get complex.

I should have been clearer: TRANSACTION is an optional server
implementation choice.  It is an addon to CQUEUE not part of it.
It was never intended that any servers had to implement it.
The only other option would be to omit the possibility entirely
which I felt would be somewhat of an oversight.

I also wasn't clear enough on this when I originally submitted it,
not only would the server need to support "TRANSACTION" but the 
client would also need to request that it wanted transaction 
semantics.  I only saw this becoming popular in the event there
developed an important use for it and the server challenges of
implementing it were overcome (which they would be if there was 
an important enough use for it).

Thanks for responding!
-- Michael --

Subject: Re: Foreknowledge  versus pipelines
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 20 May 2003 20:14:04 +0300
Sender: [email-masked]

On Mon, 2003-05-19 at 02:28, Michael Fair wrote:
> S: * Hello Welcome to the IMAP server
> S: * CAPABILITY CQUEUE STARTTLS VHOST .......
> C: tag1 CQUEUE (4)
> C: tag2 VHOST (fqdn.example.com)
> C: tag3 LANGUAGE (new_lang)
> C: tag4 STARTTLS
> C: tag5 AUTHENTICATE PLAIN

This isn't too easy to implement. At the very least server should be
able to abort the whole queue if it doesn't like it for some reason, for
example because it thinks it has too much data in it.

Still .. it would require that server reads the data into buffer before
processing any of it. And could there be literals in queue? That would
mean that server has to actually parse all the commands before executing
them. That could get tricky.

Maybe a bit easier version would be to send the commands inside a
literal so server can just read it into buffer, and it can immediately
tell the client if there's just too much data in it (literal+ shouldn't
be allowed with it).

Still, I'm not sure if this is a good idea. As limited in above example
it would work, but as a more generic feature it would just cause
problems.

> As with the GROUP proposal, as bonus points, there would 
> be an optional "TRANSACTION" parameter which would have
> a server revert to the same state prior to executing 
> the CQUEUE chain.

No, even if server used a database capable of transactions for storing
messages this would get complex.

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Subject: Foreknowledge  versus pipelines
Date: Sun, 18 May 2003 16:28:45 -0700
Organization: DaClubhouse
Sender: [email-masked]

Greetings all,

So the latest developments on trying to harmonize
on a design for reducing client side round trips
while allowing for new pre-AUTH commands like 
LANGUAGE and VHOST has come down to making a 
decision between client foreknowledge that a 
particular command is actually going to be valid 
when it is executed and allowing a client to chain 
a series of commands together that the server 
will execute in sequence.

After looking at it my self and talking it over 
with a couple others it has become more and more 
clear that the preferred approach is pipelining
or command chaining.

The LANGUAGE is already in implementation that
expects it to be its own command, and the VHOST
draft is also written with the expectation that
it be its own command.  The obvious downside to
this is that a client has to issue these each
as separate commands and for commands that can
change the CAPABILITY response is forced to wait
until that command is complete before moving on.

This proliferation of commands demands an efficient
way for clients to execute the series of them and
to ensure they get executed in the proper order.

Chris Newman shared with me that while discussing
the MULTIAPPEND command he suggested a GROUP command
that would allow a client to specify a series of 
commands in order.

In keeping with that theme I propose a command called
"CQUEUE" which would allow the client to create a 
"Command Queue" which would execute the commands in
the queue in sequence and terminate at the first 
failure (defined as a "NO" or "BAD" response).

Commands would be held up for execution until each
prior command had finished executing.  As a result
the command issued need not be valid in the current
CAPBILITY context.

The dialog would look something like this:

S: * Hello Welcome to the IMAP server
S: * CAPABILITY CQUEUE STARTTLS VHOST .......
C: tag1 CQUEUE (4)
C: tag2 VHOST (fqdn.example.com)
C: tag3 LANGUAGE (new_lang)
C: tag4 STARTTLS
C: tag5 AUTHENTICATE PLAIN
C: 
S: tag2 OK VHOST (fqdn.example.com)
S: * CAPABILITY ... new capability after VHOST ...
S: tag3 OK LANGUAGE (new_lang)
S: tag4 OK BEGIN TLS
<do the TLS negotation with the client>
S: tag4 OK STARTTLS successful
S: * CAPABILITY ... new capability after STARTTLS ...
S: +
<have the AUTHENTICATE conversation>
S: tag5 OK AUTHENTICATE successful
S: * CAPABILITY ... new capability after AUTHENTICATE ...
S: tag1 OK CQUEUE successful

I've proposed changing the name to CQUEUE from GROUP
because I felt a "Command Queue" was a bit more 
descriptive than a "Group of commands".

The primary security risk preTLS is that any command
issued goes in the clear.  As a result it is forbidden
for a client to execute a LOGIN in this manner if the
client is going to attempt to establish a TLS session.

As for the AUTHENTICATE command, that is different that
the only revealed information is what method the client
was going to request be attempted first.  Knowing which 
authentication method a client was going to request post 
TLS does not reveal any information that compromises 
the security of the TLS session or the client's data.

The client can and SHOULD monitor the execution of the
command queue as the server announces its progress.
If the command queue fails then the tag assigned to the
failed command MUST be in the "NO" response to CQUEUE
command in addition to the "NO" or "BAD" response.

As with the GROUP proposal, as bonus points, there would 
be an optional "TRANSACTION" parameter which would have
a server revert to the same state prior to executing 
the CQUEUE chain.

-- Michael --

Date: Sat, 17 May 2003 17:44:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Pete Resnick wrote:

> I've been reminded to start early on figuring out what's going on for
> the next IETF meeting, so let's do that.
>
> Document editors: Please provide to the list the status of your
> documents. Are there open issues that will need to be discussed in
> Vienna?
>
> Others: Are there items that you think need to be discussed in
> Vienna? Do remember that LEMONADE-related items should be discussed
> over there.
>
> I will be in Vienna either way. Let's figure out now whether we need a meeting.

I will be in Vienna anyway.

I should send an update revision of CONDSTORE in a week or so. Than I have some
SASL documents I have to work, but I am planning to send ACL2 update before Vienna.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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

Date: Sat, 17 May 2003 12:13:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Sender: [email-masked]

Mark Crispin wrote:

> ...

> My understanding of our status is:
>
> I) CHARTER EXTENSIONS
>
> SORT/THREAD is done, but will need to be blocked on I18N since it makes a
> normative reference to it.
>
> I believe that the remaining documents that we need to complete to fufill
> the charter are:
>
>         ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N
>
> II) NON-CHARTER EXTENSIONS.
>
> We also are considering:
>
>         LISTEXT
>
> and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired
> drafts:
>
>         QUOTA, UNSELECT
>
> I decided not to oppose UNSELECT any more; indeed, I recently implemented
> it in my server.  Cyrus server has it too.  So let's do a quick last call
> and get it published.

I will try to publish the UNSELECT document shortly.

> I vote to proceed on LISTEXT and punt on the other non-charter proposals.

I agree. QUOTA will most likely be taken by LEMONADE people anyway.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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

Date: Fri, 16 May 2003 04:39:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LAST CALL: SORT AND THREAD EXTENSION
Sender: [email-masked]

As we agreed in Atlanta, now that the IMAP i18n document is an I-D this is
a last call for draft-ietf-imapext-sort-13.txt prior to it being submitted
to the IESG.

-- Mark --

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-13.txt
Date: Fri, 16 May 2003 07:22:23 -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 - SORT AND THREAD 
                          EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-13.txt
	Pages		: 19
	Date		: 2003-5-15
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.
A server which supports the base-level SORT extension indicates this
with a capability name which starts with 'SORT'.  Future,
upwards-compatible extensions to the SORT extension will all start
with 'SORT', indicating support for this base level.
A server which supports the THREAD extension indicates this with one
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-sort-13.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-13.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-sort-13.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-sort-13.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 14 May 2003 15:41:29 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
To: Timo Sirainen <[email-masked]>, [email-masked]
Sender: [email-masked]

begin  quotation by Timo Sirainen on 2003/5/14 18:13 +0300:
> Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is
> a bit badly designed. "If there's one language, that's what got
> selected. if there's multiple ones, nothing was selected but you should
> select one of them". Kind of messy.

I agree that the design of the LANGUAGE reply is messy.  But it is also
unambiguous as defined in the spec, so I don't see a reason to change it.

> Why not have work like COMPARATOR reply?

Because they were designed by different people.

> Or maybe give the selected language as resp-text-code in tagged
> OK reply?

That would be inconsistent with other IMAP commands that adjust server state.
So I don't see it as better from an aesthetic point of view.

> I think he means something like:
> 
> 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP
> Extensions") 1 OK
> 2 LIST (ANNOTATION ("alias")) "" %
> * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/"
> "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions"))))
> "/" "ietf-imapext" 2 OK
> 
> INBOX and maybe some other site global mailbox names could be predefined
> for multiple languages which would be used after client has selected
> language.

So maybe the ANNOTATEMORE extension should define a namespace for localized
mailbox names?  Sounds reasonable to me.

> Looks like LISTEXT and ANNOTATEMORE don't play together currently.
> Should they? I'd like the possibility to do above.

I concur.

> Other issues in the draft:
> 
> "Clients MUST re-issue the LANGUAGE command once a security layer is
> active" is mentioned only in "security considerations. I think it should
> be mentioned in section 3.2 also.
> 
> You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does
> sorting by subject.

OK.  Will fix these two in the next version.

                - Chris

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Chris Newman" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Wed, 14 May 2003 12:51:13 -0700
Organization: DaClubhouse
Sender: [email-masked]

> On Wed, 14 May 2003, Michael Fair wrote:
> > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)
>
> This is a contrived example.
>
> It's impossible to pipeline anything after STARTTLS.  In fact, it's
> impossible to even think about transmitting anything after STARTTLS, since
> you need to do the key exchange negotiation before you have the physical
> capability of transmitting the AUTHENTICATE.

Sorry I was confusing the existing mechansims with the work I
was doing on ECAPABILITY which was attempting to reduce round
trips by asking the client for information as it needed it
(thus STARTTLS would negotiate and once completed the server
 would immediately begin the AUTH conversation (lest the method
 requested wasn't supported and would therefore stop, requiring
 the client to issue a CAPABILTIY to find out what methods
 were supported).

Even barring that ability, just drop the AUTH command off the
end and the example still holds.

The point is that pipelining and foreknowledge are mutually
exclusive for most commands prior to AUTH because most of
the important pre-auth commands change the CAPABILITY response.
As a result, a client must issue a command, wait for the response,
get the new capability list, issue the next command, wait, issue
the next command, wait.

A more detailed state progress of the above example as currently
implemented by the proposed solutions:

1) Client shows up at server gets hello and requests CAPABILITY
   server sends LANGUAGE VHOST (but not STARTTLS, AUTH, or LOGIN)
2) Client issues the LANGUAGE command
3) Client issues the VHOST command
***** Client waits *****
4) Client gets new CAPABILTIY and the server now issues
   LANGUAGE VHOST STARTTLS LOGIN and AUTH (but not AUTH plain)
5) Client issues STARTTLS and does the negotation
***** Client waits *****
6) Client gets the new CAPABILTIY and the server now issues
   LANGUAGE VHOST STARTTLS LOGIN and AUTH including AUTH plain
7) Client issues AUTH using the plain mechanism
***** Client waits *****
8) Client gets the new CAPABILTIY and is now ready to begin
   the real IMAP session work

Same example with the method I was envisioning:
1) Client shows up at server gets hello
2) Client issues a new version of PIPELINE (with ordering
   and negotiation support) with the following chain:
LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)
***** Client watches responses as the server executes each *****
***** Client waits for BAD, NO, or STARTTLS *****
3) Client does STARTTLS negotiation
***** Client waits for BAD, NO, or AUTH negotiation *****

If the client receives BAD or NO it knows what state it
is in because the server issued and OK for every command
that succeeded.  Once an error occurs in the command chain
processing of the chain stops.

-- Michael --

Date: Wed, 14 May 2003 12:28:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 May 2003, Michael Fair wrote:
> LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)

This is a contrived example.

It's impossible to pipeline anything after STARTTLS.  In fact, it's
impossible to even think about transmitting anything after STARTTLS, since
you need to do the key exchange negotiation before you have the physical
capability of transmitting the AUTHENTICATE.

I'm finding it very difficult to read your messages.  Could you please get
to the point in a more consise fashion?

-- Mark --

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

Date: Wed, 14 May 2003 12:28:19 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

I can't wade through your long message to answer it point-by-point, but
here is a pedagogical explanation:

LEMONADE has identified a need to send messages containing content from a
mailbox in an IMAP server.  It is costly, especially for embedded devices,
to fetch the content from an IMAP server just to send it back out to an
SMTP server.

On the other hand, if the message submission server is not co-located with
the IMAP server, then the submission server must have full IMAP access to
the user's account on the IMAP server.  This is perceived as a security
risk.

Consequently, it was proposed to use an IMAP server as a mesasge
submission agent, by submitting the message with "include such-and-such
text from such-and-such mailbox" pointers, which the IMAP server will
acquire locally.

As a counter proposal, I suggest a means by which an IMAP client can
create a limited access token, which can access only the necessary data
but not any other data.  This limited access token can be used by the
message submission server to obtain the data from the IMAP server without
giving the message submission server access to any other user data.

This also permits the message submission server to access data from
multiple IMAP servers.  Furthermore, it does not create a situation in
which IMAP duplicates the functionality of other protocols.

-- Mark --

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

From: "Michael Fair" <[email-masked]>
To: "Chris Newman" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Wed, 14 May 2003 11:23:51 -0700
Organization: DaClubhouse
Sender: [email-masked]

> begin quotation by Michael Fair on 2003/5/13 11:45 -0700:
> > Is there anything else anyone else saw that seems to make
> > this whole client side CAPABILITY approach to items like
> > VHOST and LANGUAGE (and perhaps a CHARSET could be added
> > to the list for UTF-8 support?) a bad idea?
>
> We discussed the issue of client capabilities at the informal
> IMAPEXT BOF at
> the last IETF and there was a rough consensus in the room (of about 20
> IMAP developers many of whom write code) which opposed the idea of a
> combined client capability mechanism.  The rough consensus of the
> room appeared to favor separate commands which could be pipelined
> rather than a combined command.  Now the mailing list can override
> that consensus, but I'd need to see stronger support than I've seen
> to date.

No one prior to you had ever mentioned that.  Wish I would have known
would have saved me some trouble. :)

Creating a command pipeline works for me.  I actually like that
even more, but it seems to break with what a few ppl have said
to me earlier in that they really don't like the idea of a client
trying a command to find out if it will work or not.  The general
premise is that a client should always have foreknowledge that
the command they want to use is valid.

But there's a problem with this, since pretty much every commonly
used command prior to authenticating has the potential to
change the "environment" (read CAPABILITY response) then
pipelining and foreknowledge are somewhat mutually exclusive
in that using one denies the other.

As an example, a client wants to execute:
LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)

Even though this might be a very valid sequence there's no way
for a client to know whether or not this will work without stopping
at each point and waiting for the response.  STARTTLS might not
be available till after VHOST and AUTH plain might further not
be available until after STARTTLS.

I also understood that servers can reorder commands so depending
on the order executed the above means different things and it's
success rate differs depending on the order executed.

I personally prefer pipelining much more than foreknowledge on
principal because the errors generated by usage of this nature
uses a very minor number of resources in comparison to the
possible efficiency gains and 9 times out of 10 the client is
just checking to make sure the server does something that
already has a more than reasonable chance at succeeding.

The only con is that it demands proper failure behavior which
should be, but is not always what's out there.  However,
protecting clients that don't check return codes and servers
that don't generate them by not implementing a feature that
could give trmendous efficiency gains for those that do the
proper thing seems like it's asking for trouble.

Since the commands will succeed the majority of the time, it
seems wasteful to cause the login process to be longer just
for a psuedo-gaurantee that it will succeed.  This is further
compounded by things admins can do to tain their environmnent.
Clients might be able to be configured for, or discover
and remember, success "paths" for the servers they access and
not be forced to stop and wait at each step every login.

If clients/servers all do some basic error checking then
pipelining would simply trip over the error codes and the
clients can issue the proper commands to get the info to
determine how to proceed.  Of course I believe that the
client would need a way to specify the order in which the
commands get executed (lest the command fail otherwise).

I can see the merits of both approaches, but it seems that
the consensus is that reducing round trips is important.
The only way I see that happening is by giving up the notion
that a client should always have foreknowledge that the
commands they are issuing are valid when it comes to being
able to pipeline commands.  Instead, it shoud be that a client
can try an optimistic pipeline expecting a chain to succeed
and the pipeline should stop executing at the first failure.

Assuming that people can live with that, I think the
multiple commands with a pipeline provision is the best
route as well.

> In addition, there is deployed running code for the LANGUAGE extension
> (implemented to the previous draft).  As a result I am opposed to
aesthetic
> changes to the LANGUAGE extension as documented.  Proposed changes need to
have
> a substantive technical justification.

The only technical justification was discussed above.

> > 2) In specific response to the LANGUAGE feature set as
> > described, I noticed it is missing in-band administration
> > for assigning the various LANGUAGE translations of folders.
> >
> > 3) Could this be extended to allow all folders to be
> > represented in multiple languages by way of some kind
> > of "ALIAS" command that could install a language alias
> > for folders?  This would probably require the equivalent
> > of a RENAME ACL.  This would anticipate a resolution
> > to the lack of character set choice currently present.
> > (For instance via a client capability mentioned above.)
>
> Please make a concrete proposal if you want to discuss these
> issues.  I'm not sure exactly what you're asking so it would
> be easier to discuss if I could see something concrete.
>
> > 4) Since languages are somewhat tied to character sets,
>
> The selected character set is always UTF-8, so there is no issue.

I was basing the character set issues off of section 5.2.
Ok so 2,3 and 4 were all related, and I might be generalizing
a feature that's not actually in the draft.

Timo's SETANNOTATION example of creating aliases for INBOX and
ietf-imapext folders were an example of how this might be used
but I wasn't expecting it to be used to create aliases in the
same language (though I think that would be useful).  Further,
the only folders that can currently be "localized" are the
folders in NAMESPACE.  There might be a technical reason for
that.  What I was envisioning was a way to name any mailbox in
many languages by assigning several language specific aliases.

This was primarily to facilitate "Shared Folders" in organizations
where people who use multiple languages share the same folder.
For instance, the folder "Technical Support" would be a general
box for incoming issues in multiple languages.  The support staff
reading this mailbox speak different languages, and as a result
would like the "Technical Support" folder to display its name
in their native language.  If they could attach a language
specific alias for the foldername, they could do this.

This would also satisfy the method by which namespace translations
would be set.  They would be treated just like any other folder
for the purpose of setting the translation to begin with.

Secondarily, if assigning aliases to arbitrary folders is
not technically feasible for some reason, then there should
still be a defined method to set the aliases for the folders
returned by NAMESPACE.  While the current draft describes how
the server should format and respond to a client to provide
the NAMESPACE response with translations, it doesn't specify
any method to set those translations in the first place.
This may just be a "server must be preconfigured" thing, but
it seems to me that there should be an IMAP command for this.

I do not feel the slightest bit qualified to recommend a
method to set the translations.  Timo's SETANNOTATION
seemed like a decent enough approach however it would
require the addition of a language parameter.

Which brings up another question, are the language names
going to support the localized variants like en_US and fr_CA?
If so, does it need any special mentioning?  For instance a
phrase like "localized variants of a language if not explicity
supported may match on either a non-localized version of the
same language or if that's not available, then another variant
of the same language.  If there are no variants of the language
supported by the server (localized or not) then the match
SHOULD fail."  I don't know if it really matters, but I expect
it'll come up sooner or later.

-- Michael --

Date: Wed, 14 May 2003 11:16:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Sender: [email-masked]

Hi Chris,

--On Tuesday, May 13, 2003 3:09 PM -0700 Chris Newman 
<[email-masked]> wrote:

| So I am now willing to see SORT and THREAD move forward without VIEW
| despite my scalability concerns.  Given how busy and resource limited the
| IMAP community appears to be at the moment, I further propose we drop the
| VIEW command from the list of WG deliverables we must complete prior to
| WG closure (but let's not bother changing the charter until we've
| finished the other deliverables).

I fully agree with this position.

-- 
Cyrus Daboo

Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 14 May 2003 18:13:51 +0300
Sender: [email-masked]

On Tue, 2003-05-13 at 23:57, Chris Newman wrote:
> In addition, there is deployed running code for the LANGUAGE extension
> (implemented to the previous draft).  As a result I am opposed to aesthetic
> changes to the LANGUAGE extension as documented.  Proposed changes need to have
> a substantive technical justification.

Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is
a bit badly designed. "If there's one language, that's what got
selected. if there's multiple ones, nothing was selected but you should
select one of them". Kind of messy. Why not have work like COMPARATOR
reply? Or maybe give the selected language as resp-text-code in tagged
OK reply?

> > 2) In specific response to the LANGUAGE feature set as
> > described, I noticed it is missing in-band administration
> > for assigning the various LANGUAGE translations of folders.
> >
> > 3) Could this be extended to allow all folders to be
> > represented in multiple languages by way of some kind
> > of "ALIAS" command that could install a language alias
> > for folders?  This would probably require the equivalent
> > of a RENAME ACL.  This would anticipate a resolution
> > to the lack of character set choice currently present.
> > (For instance via a client capability mentioned above.)
> 
> Please make a concrete proposal if you want to discuss these issues.  I'm not
> sure exactly what you're asking so it would be easier to discuss if I could see
> something concrete.

I think he means something like:

1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP Extensions")
1 OK
2 LIST (ANNOTATION ("alias")) "" %
* LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" "INBOX"
* LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) "/" "ietf-imapext"
2 OK

INBOX and maybe some other site global mailbox names could be predefined
for multiple languages which would be used after client has selected
language.

Looks like LISTEXT and ANNOTATEMORE don't play together currently.
Should they? I'd like the possibility to do above.

Other issues in the draft:

"Clients MUST re-issue the LANGUAGE command once a security layer is
active" is mentioned only in "security considerations. I think it should
be mentioned in section 3.2 also.

You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does
sorting by subject.

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Vienna
Date: Tue, 13 May 2003 22:09:54 -0700
Organization: DaClubhouse
Sender: [email-masked]

> 2) LEMONADE.
>
> LEMONADE clearly identified a need for message submission that does not
> require downloading from IMAP server; however, doing submission in IMAP is
> a mistake.  I'd rather not argue the reasons why in email; it'll
> just waste everybody's time.
>
> Instead, let's come up with an alternative so there is a choice that can
> be made.  Right now, there is no choice.
>
> I suggest a command, valid when not logged in, that will fetch a
> particular message or portion of message.  Thus, the argument to the
> command has to carry authentication of some kind; the key is that this is
> *not* the user's authentication but rather some special authentication
> that is specific to that message or portion of a message.
>
> Desirable authentication forms: use-once, anonymous, use only by certain
> entity, time-limited (e.g. "expires in 5 minutes").
>
> Could be a SASL mechanism, since SASL has the framework; ultimately
> returning a NO so it can be done multiple times in one IMAP connection.
>
> Must be expressable in an IMAP URL; the URL must carry the authentication
> (possibly also with a client-supplied token).
>
> The idea here is that the MSA is given a message with various IMAP URLs
> inserted.  The MSA resolves the URL and fetches the data from the server
> (or servers -- an advantage of doing it this way).
>
> We need a command for an IMAP client to create these things, e.g. "give me
> a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
> 12383 from my INBOX".

Please correct me if I'm wrong, let me see if I can
recap what you are proposing since I've gotten confused
about what seems to be mixed or at least unclarified
usage of the terms submission, client, and server.

1) It is inappropriate to make the IMAP server the middle man
   for transporting messages.  The client should have a method
   of requesting data directly from foriegn servers
   (aka "message submission that does not require downloading
    from IMAP server")?
   You chose not to waste people's time with the details of
   an explanation.  So you chose to propose a new IMAP command
   so we can compare and choose.

2) This new command is to provide a way for an end user client
   to tell an IMAP server to fetch arbirtrary message parts with
   authentication.  And that relates to message submission because
   the server is to fetch the data from the remote server and
   store the retrieved data as part of the message in the local
   mail store?  Or this command is intended to be issued by remote
   servers and/or clients who are trying to "pick up" the message
   parts from the current server?
   Or this has nothing to do with message submission and is about
   an end user client getting fast access to a separate IP connection
   (whether or its own use or some other agent's use) through which
   to transfer the data across with?

   It's not clear to me whether the ultimate intended recipient
   of this command is the IMAP server, the end user client, or some
   other remote service that was told to pick up the data.

You then described the authentication requirements.

3) You then concluded with describing the general idea as the
   MSA gets handed a message with a bunch of URLs and goes off
   to do its thing.  But I'm not clear on who the MSA is being
   an agent of.  Given your example it seems that intended
   destination is an end user client who already as a session
   with the current server and that the definition of "submission"
   is actually a transfer from server space to end user space
   rather than the user space submitting to server space.
   (I use server space as loose term to refer to the collection
    of servers hosting the message data, and user space as the
    collection of clients being used to view it)

I have not been following LEMONADE to really get what the current
intended framework looks like.  So it might be that I'm just missing
some background info that I haven't read yet.

Unfortunately, without clarity on exactly what the envisioned
framework is I am having a hard time picturing the overall use
and goal here.  I might also be having a hard time because I
have a general definition of submission as "moving away from
the source", of "uploading" as moving away from the current
active end user, and of "downloading" as moving to the active
service.  I just can't clearly tell what the various active
objects in your description are and when they are being active.

If the ultimate goal here to provide an end user client with
a URL so that the end user client (or local agent) can open
up another connection to the same server and quickly access
the data, then I'd think simply providing a method for doing
a "FASTAUTH" token which would at most need to renegotiate TLS
to establish the same context as the initial session is all
that would be required because then the new session can issue
the same IMAP commands the other could.
But that would leave the heavy lifting "in IMAP" which
you don't think will work.  (Because the connecting agent may
not know any IMAP over and above submitting this command?)

Further, if the purpose is really just to give other
applications on the same client machine access to the
data,  then why not have the client act as a relay between
the IMAP server and the final application.  It could
easily do this by opening a port bound to the 127.0.0.1
interface and then causing whatever Agent to connect
to that loopback port while the IMAP client then transferred
the data across via IMAP.  This allows the IMAP client to
cache the message part and provide the data to the external
application at the same time.  It further supplies a
methodology for the same dat to be viewed by the end user
multiple times without transferring from the server each time.
This method doesn't work so well for real time protocols.
Those will probably have to be handled differently unless
the server and client learn to speak RTSP.

If the purpose is to allow clients to request URLs that
are to be issued to a server other than the one the client
is talking to at the moment then I think I understand
what you're trying to accomplish.  The current server
has a message whose parts are stored in many locations,
the client wants to access these parts and therefore
requests a token from the current server to fetch them.
The questions I have then are, is it expected that all
the remote servers are IMAP servers, or are they arbitrary
protocols?  Assuming IMAP its various IMAP servers involved
then are they preaware of each other's existence?  Can the
servers share a secret between each other for generating
the URLs (perhaps PKI based?)?

If the purpose is actually to enable clients to upload data
(aka submit new data to the server) then I'm having a hard
time comprehending the client requesting a cookie to fetch
the message part.

Finally if I'm way off base on all of these, and you really
just need a simple command to fetch data, then I suggest the
command mimic the HTTP protocol (with recent extensions) as
closely as possible to leverage as much existing work and
mind share done in this area as possible (unless of course
there is some technical reason that makes this impractical.

Sorry for the long email but I just wanted to be clear about
what the vaious confusions were.

Thank you,
-- Michael --

Date: Tue, 13 May 2003 16:59:55 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 13 May 2003, Chris Newman wrote:
> So I am now willing to see SORT and THREAD move forward without VIEW
> despite my scalability concerns.  Given how busy and resource limited
> the IMAP community appears to be at the moment, I further propose we
> drop the VIEW command from the list of WG deliverables we must complete
> prior to WG closure (but let's not bother changing the charter until
> we've finished the other deliverables).

Thank you.

My understanding of our status is:

I) CHARTER EXTENSIONS

SORT/THREAD is done, but will need to be blocked on I18N since it makes a
normative reference to it.

I believe that the remaining documents that we need to complete to fufill
the charter are:

	ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N

II) NON-CHARTER EXTENSIONS.

We also are considering:

	LISTEXT

and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired
drafts:

	QUOTA, UNSELECT

I decided not to oppose UNSELECT any more; indeed, I recently implemented
it in my server.  Cyrus server has it too.  So let's do a quick last call
and get it published.

I vote to proceed on LISTEXT and punt on the other non-charter proposals.

-- Mark --

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

Date: Tue, 13 May 2003 15:09:15 -0700
From: Chris Newman <[email-masked]>
Subject: SORT, THREAD and VIEW/WINDOW
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

There is a scalability problem with the design of SORT and THREAD because their
performance and bandwidth consumption depends on the number of messages in the
mailbox.  As a result of this problem, I held the position that we need to hold
up SORT and THREAD until the VIEW command is ready to move forward on the
standards track at the same time.

After going through a number of revisions on VIEW and WINDOW proposals with
Cyrus, my position has changed slightly.  I now recognize that the VIEW command
(or similar mechanism) would introduce significant complexity and that
complexity may exceed the benefit it provides.  In particular, the majority of
users may be satisfied to keep the size of the mailboxes on which they apply
SORT and THREAD to some reasonable limit (e.g., less than 10,000 messages) in
order to get acceptable performance.  Scalable servers might cache SORT and
THREAD results so the computation cost is minimized and perhaps bandwidth is
increasing fast enough that it isn't a concern.

So I am now willing to see SORT and THREAD move forward without VIEW despite my
scalability concerns.  Given how busy and resource limited the IMAP community
appears to be at the moment, I further propose we drop the VIEW command from
the list of WG deliverables we must complete prior to WG closure (but let's not
bother changing the charter until we've finished the other deliverables).

                - Chris

Date: Tue, 13 May 2003 13:57:04 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
To: Michael Fair <[email-masked]>, [email-masked]
Sender: [email-masked]

begin quotation by Michael Fair on 2003/5/13 11:45 -0700:
> Four things:
> 
> 1) Lately there's been talk of moving commands like these
> into a client CAPABILITY announcement string.  The command
> has been proposed as a way for the client to:
> 
> A) Announce capabilities it has that the server
>    might be able to do something special with,
> and
> B) Set options to server capabilities that impact the
>    behavior of the session
> 
> The two major candidates in most examples so far have
> been VHOST and LANGUAGE.  I didn't see anything requested
> here that would preclude LANGUAGE from being assigned
> in that manner.  The only "special case" I saw is that
> any client issuing a CAPABILITY with a LANGUAGE option
> MUST be prepared to receive an untagged NAMESPACE response
> as one of the responses to CAPABILITY.
> 
> Is there anything else anyone else saw that seems to make
> this whole client side CAPABILITY approach to items like
> VHOST and LANGUAGE (and perhaps a CHARSET could be added
> to the list for UTF-8 support?) a bad idea?

We discussed the issue of client capabilities at the informal IMAPEXT BOF at
the last IETF and there was a rough consensus in the room (of about 20 IMAP
developers many of whom write code) which opposed the idea of a combined client
capability mechanism.  The rough consensus of the room appeared to favor
separate commands which could be pipelined rather than a combined command.  Now
the mailing list can override that consensus, but I'd need to see stronger
support than I've seen to date.

In addition, there is deployed running code for the LANGUAGE extension
(implemented to the previous draft).  As a result I am opposed to aesthetic
changes to the LANGUAGE extension as documented.  Proposed changes need to have
a substantive technical justification.

> 2) In specific response to the LANGUAGE feature set as
> described, I noticed it is missing in-band administration
> for assigning the various LANGUAGE translations of folders.
>
> 3) Could this be extended to allow all folders to be
> represented in multiple languages by way of some kind
> of "ALIAS" command that could install a language alias
> for folders?  This would probably require the equivalent
> of a RENAME ACL.  This would anticipate a resolution
> to the lack of character set choice currently present.
> (For instance via a client capability mentioned above.)

Please make a concrete proposal if you want to discuss these issues.  I'm not
sure exactly what you're asking so it would be easier to discuss if I could see
something concrete.

> 4) Since languages are somewhat tied to character sets,
> it seems logical that in response to the LANGUAGE command
> aside from the language selected the character set used
> by the server to display that language should also be
> announced shouldn't it?  I've done no internationalization
> work so I'm not sure how you get two machines to align
> on a character set implicity through just a language name.

The selected character set is always UTF-8, so there is no issue.

                - Chris

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Tue, 13 May 2003 11:45:45 -0700
Organization: DaClubhouse
Sender: [email-masked]

Four things:

1) Lately there's been talk of moving commands like these
into a client CAPABILITY announcement string.  The command
has been proposed as a way for the client to:

A) Announce capabilities it has that the server
   might be able to do something special with,
and
B) Set options to server capabilities that impact the
   behavior of the session

The two major candidates in most examples so far have
been VHOST and LANGUAGE.  I didn't see anything requested
here that would preclude LANGUAGE from being assigned
in that manner.  The only "special case" I saw is that
any client issuing a CAPABILITY with a LANGUAGE option
MUST be prepared to receive an untagged NAMESPACE response
as one of the responses to CAPABILITY.

Is there anything else anyone else saw that seems to make
this whole client side CAPABILITY approach to items like
VHOST and LANGUAGE (and perhaps a CHARSET could be added
to the list for UTF-8 support?) a bad idea?

2) In specific response to the LANGUAGE feature set as
described, I noticed it is missing in-band administration
for assigning the various LANGUAGE translations of folders.

3) Could this be extended to allow all folders to be
represented in multiple languages by way of some kind
of "ALIAS" command that could install a language alias
for folders?  This would probably require the equivalent
of a RENAME ACL.  This would anticipate a resolution
to the lack of character set choice currently present.
(For instance via a client capability mentioned above.)

4) Since languages are somewhat tied to character sets,
it seems logical that in response to the LANGUAGE command
aside from the language selected the character set used
by the server to display that language should also be
announced shouldn't it?  I've done no internationalization
work so I'm not sure how you get two machines to align
on a character set implicity through just a language name.

-- Michael --

----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
Sent: Tuesday, May 13, 2003 5:00 AM
Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Internet Message Access Protocol
Extension Working Group of the IETF.
>
> Title : Internet Message Access Protocol Internationalization
> Author(s) : C. Newman
> Filename : draft-ietf-imapext-i18n-00.txt
> Pages : 18
> Date : 2003-5-12
>
> Internet Message Access Protocol (IMAP) version 4rev1 has basic
> support for non-ASCII characters in mailbox names and search
> substrings.  It also supports non-ASCII message headers and content
> encoded as specified by Multipurpose Internet Mail Extensions (MIME).
> This specification defines a collection of IMAP extensions which
> improve international support including comparator negotiation for
> search, sort and thread, language negotiation for international error
> text, and translations for namespace prefixes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> 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-i18n-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-ietf-imapext-i18n-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.
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Tue, 13 May 2003 08:00:15 -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 Internationalization
	Author(s)	: C. Newman
	Filename	: draft-ietf-imapext-i18n-00.txt
	Pages		: 18
	Date		: 2003-5-12
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions (MIME).
This specification defines a collection of IMAP extensions which
improve international support including comparator negotiation for
search, sort and thread, language negotiation for international error
text, and translations for namespace prefixes.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-i18n-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-ietf-imapext-i18n-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-00.txt

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

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

--OtherAccess--

--NextPart--

To: Mark Crispin <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
From: Simon Josefsson <[email-masked]>
Date: Tue, 06 May 2003 23:56:43 +0200
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:

> I suggest a command, valid when not logged in, that will fetch a
> particular message or portion of message.  Thus, the argument to the
> command has to carry authentication of some kind; the key is that this is
> *not* the user's authentication but rather some special authentication
> that is specific to that message or portion of a message.
>
> Desirable authentication forms: use-once, anonymous, use only by certain
> entity, time-limited (e.g. "expires in 5 minutes").
>
> Could be a SASL mechanism, since SASL has the framework; ultimately
> returning a NO so it can be done multiple times in one IMAP connection.
>
> Must be expressable in an IMAP URL; the URL must carry the authentication
> (possibly also with a client-supplied token).
>
> The idea here is that the MSA is given a message with various IMAP URLs
> inserted.  The MSA resolves the URL and fetches the data from the server
> (or servers -- an advantage of doing it this way).
>
> We need a command for an IMAP client to create these things, e.g. "give me
> a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
> 12383 from my INBOX".

SASL together with a short-lived Kerberos ticket is a somewhat heavy
solution (even heavier if GSSAPI is involved), but possible.

It could be done with a short-lived username/password combination too,
although more difficult to embed useful information you can store in
the ticket (like who created the ticket, useful for logging).

The server could log on the user, using the short-lived authorization
information, and present a restricted view of the mailboxes: only the
appropriate message is available, from one mailbox (INBOX).

SASL definitely has the framework for this, and using it wouldn't
require changes to the IMAP URL either.

My $.2.

Date: Tue, 6 May 2003 14:45:45 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 May 2003, Cyrus Daboo wrote:
> Surely its enough to simply require ACL and require that the MSA have an
> associated user id on the IMAP server and that it be given read/write
> access to each 'real' users' OUTBOX?

No, part of the design is that the MSA does *NOT* have access to anything
that it is not given specific access.

Also, I'm thinking that this may be useful for other things; perhaps I
might want to send someone an email with such a URL (as opposed to the
actual data).

-- Mark --

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

Date: Tue, 06 May 2003 17:44:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Hi Pete,

--On Tuesday, May 6, 2003 10:15 AM -0500 Pete Resnick 
<[email-masked]> wrote:

| Document editors: Please provide to the list the status of your
| documents. Are there open issues that will need to be discussed in Vienna?
|

I have to catch up on the changes to ANNOTATE/ANNOTATEMORE from the last 
meeting - sorry. I will try and get around to that by the end of this week.

| I will be in Vienna either way. Let's figure out now whether we need a
| meeting.

I will not be waltzing over to Vienna :-(

-- 
Cyrus Daboo

Date: Tue, 06 May 2003 17:41:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Hi Mark,

--On Tuesday, May 6, 2003 2:20 PM -0700 Mark Crispin 
<[email-masked]> wrote:

| The idea here is that the MSA is given a message with various IMAP URLs
| inserted.  The MSA resolves the URL and fetches the data from the server
| (or servers -- an advantage of doing it this way).
|
| We need a command for an IMAP client to create these things, e.g. "give me
| a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
| 12383 from my INBOX".

Surely its enough to simply require ACL and require that the MSA have an 
associated user id on the IMAP server and that it be given read/write 
access to each 'real' users' OUTBOX? Its then a simple matter to write a 
dedicated IMAP client for the MSA that goes and gets messages from each 
OUTBOX on the IMAP server. If you combine this with async notifications for 
STATUS changes (i.e. when a message is added to an OUTBOX) there shouldn't 
be any need to pass a URL to the MSA.

-- 
Cyrus Daboo

Date: Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 May 2003, Pete Resnick wrote:
> Document editors: Please provide to the list the status of your
> documents.

SORT/THREAD: awaiting Chris Newman's i18n document to come out as an I-D
before making Last Call.

> Are there open issues that will need to be discussed in
> Vienna?

Since both UW and Cyrus now implement Alexey's UNSELECT extension, let's
Last Call it.  The I-D is expired.

> Others: Are there items that you think need to be discussed in
> Vienna? Do remember that LEMONADE-related items should be discussed
> over there.

Two things come to mind:

1) Does Chris need help with the i18n I-D?  If so, he should get it.

2) LEMONADE.

LEMONADE clearly identified a need for message submission that does not
require downloading from IMAP server; however, doing submission in IMAP is
a mistake.  I'd rather not argue the reasons why in email; it'll
just waste everybody's time.

Instead, let's come up with an alternative so there is a choice that can
be made.  Right now, there is no choice.

I suggest a command, valid when not logged in, that will fetch a
particular message or portion of message.  Thus, the argument to the
command has to carry authentication of some kind; the key is that this is
*not* the user's authentication but rather some special authentication
that is specific to that message or portion of a message.

Desirable authentication forms: use-once, anonymous, use only by certain
entity, time-limited (e.g. "expires in 5 minutes").

Could be a SASL mechanism, since SASL has the framework; ultimately
returning a NO so it can be done multiple times in one IMAP connection.

Must be expressable in an IMAP URL; the URL must carry the authentication
(possibly also with a client-supplied token).

The idea here is that the MSA is given a message with various IMAP URLs
inserted.  The MSA resolves the URL and fetches the data from the server
(or servers -- an advantage of doing it this way).

We need a command for an IMAP client to create these things, e.g. "give me
a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
12383 from my INBOX".

> I will be in Vienna either way. Let's figure out now whether we need a
> meeting.

I won't be in Vienna.

-- Mark --

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

Date: Tue, 6 May 2003 10:15:35 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Vienna
Sender: [email-masked]

I've been reminded to start early on figuring out what's going on for 
the next IETF meeting, so let's do that.

Document editors: Please provide to the list the status of your 
documents. Are there open issues that will need to be discussed in 
Vienna?

Others: Are there items that you think need to be discussed in 
Vienna? Do remember that LEMONADE-related items should be discussed 
over there.

I will be in Vienna either way. Let's figure out now whether we need a meeting.
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Cc: "Harrie Hazewinkel" <[email-masked]>
Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips)
Date: Mon, 5 May 2003 18:22:49 -0700
Organization: DaClubhouse
Sender: [email-masked]

I'm looking forward to hearing what others also have to
say about this.

It seems to me that two or three drafts should be used to
replace the current VHOST draft based on this discussion.

While I may have the details wrong, in general, the three
drafts seem to be something along the lines of the following:

1) ECAPABILITY draft (nobody seems to mind ECAPABILITY keyword).
   - This creates ECAPABILITY as a CAPABILITY keyword and
     means that the CAPABILITY command accepts parameters
     for the purposes of informing the server of client
     capabilities and for passing options to capabilities
     the server supports.

2) VHOST draft
   - Redefines VHOST in the context of ECAPABILITY as per
     the details of this discussion.

3) Notification of CAPABILITY as unsolicited responses draft
   - In order to save round trips, allows a server to post
     an unsolicitied CAPABILITY response after the client
     executes any command that changes the CAPABILITY set.
     Currently the identified responses are HELLO, STARTTLS,
     ECAPABILITY, LOGIN, and AUTHENTICATE.  I'd imagine
     that in some servers other commands (like "SELECT")
     might also want/need this ability.

It would also seem that other ideas and drafts might be
recontextualized via ECAPABILITY as well.  For instance,
the LANGUAGE thread that went on a while ago might give
servers the opportunity to store and manipulate folders
in multiple languages and allow the client to define a
preferred language priority list.  Something would have
to be done to allow clients to attach folder names in
different languages to exisitng folders, but that's
outside the scope of the ECAPABILITY draft.

My $0.02,
-- Michael --

----- Original Message ----- 
From: "Harrie Hazewinkel" <[email-masked]>
To: <[email-masked]>
Cc: "Harrie Hazewinkel" <[email-masked]>; "Michael Fair"
<[email-masked]>
Sent: Monday, May 05, 2003 6:54 AM
Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login"
(saving round trips)

> HI all,
>
>
> As being the author of that 'VHOST' command internet-draft
> I was wondering if the group believes it is usefull
> to recycle that draft based on the summary/idea/consensus
> of this discussion??
>
>
> Harrie
>
> On Friday, May 2, 2003, at 05:16 AM, Michael Fair wrote:
>
> >
> >> The really important thing is avoiding round-trips. The
> >> amount of bandwidth
> >> that is taken up by capabilities is really dwarfed by
> >> any messages the client downloads.
> >>
> >> It would be nice, if you're redoing how capabilities
> >> are announced, to do
> >> away with the pointless roundtrips after STARTTLS and
> >> after authentication.
> >
> > I've renamed the subject to reflect the topic.  It's
> > become pretty clear to me that this issue is important
> > but is really separate from adding parameters to the
> > CAPABILITY command.
> >
> > So far the suggestions are to automatically append
> > a CAPABILITY response to any command that changes
> > the current CAPABILITY set.  So far those responses
> > are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if
> > accepted ECAPABILITY.
> >
> > This really sounds more like IMAP4rev2ish but I
> > would suggest including something like:
> >
> > - A Client MUST be prepared to receive an unsolicited
> >   CAPABILITY response after the status response code
> >   of any command.
> >
> > If you wanted to restrict that to "state altering"
> > commands that would probably work too.
> >
> > -- Michael --
>
>

From: "Michael Fair" <[email-masked]>
To: "Lawrence Greenfield" <[email-masked]>, "Timo Sirainen" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips)
Date: Thu, 1 May 2003 20:16:44 -0700
Organization: DaClubhouse
Sender: [email-masked]

> The really important thing is avoiding round-trips. The 
> amount of bandwidth 
> that is taken up by capabilities is really dwarfed by 
> any messages the client downloads.
> 
> It would be nice, if you're redoing how capabilities 
> are announced, to do 
> away with the pointless roundtrips after STARTTLS and 
> after authentication.

I've renamed the subject to reflect the topic.  It's
become pretty clear to me that this issue is important
but is really separate from adding parameters to the
CAPABILITY command.

So far the suggestions are to automatically append
a CAPABILITY response to any command that changes
the current CAPABILITY set.  So far those responses
are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if
accepted ECAPABILITY.

This really sounds more like IMAP4rev2ish but I
would suggest including something like:

- A Client MUST be prepared to receive an unsolicited
  CAPABILITY response after the status response code 
  of any command.

If you wanted to restrict that to "state altering"
commands that would probably work too.

-- Michael --

Date: Thu, 01 May 2003 20:22:27 -0400
From: Lawrence Greenfield <[email-masked]>
To: Timo Sirainen <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: Michael Fair <[email-masked]>, [email-masked]
Subject: Re: Adding a parameter to CAPABILITY
Sender: [email-masked]

--On Friday, May 02, 2003 12:47 AM +0300 Timo Sirainen <[email-masked]> wrote:

>
> On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote:
>> For better compatibility with clients that won't understand ECAPABILITY
>> I  think ECAPABILITY should be a capability value itself. This means
>> that the  greeting string can continue to display the CAPABILITY
>> response code that  some servers now return, but would include
>> ECAPABILITY as one its items:
>>
>> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to
>> you!
>
> I don't really like sending the capability to client automatically. That
> also means that we would receive the capability twice, once at start and
> next after issuing CAPABILITY VHOST (..).

The really important thing is avoiding round-trips. The amount of bandwidth 
that is taken up by capabilities is really dwarfed by any messages the 
client downloads.

It would be nice, if you're redoing how capabilities are announced, to do 
away with the pointless roundtrips after STARTTLS and after authentication.

Larry

From: "Michael Fair" <[email-masked]>
To: "Timo Sirainen" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 16:00:57 -0700
Organization: DaClubhouse
Sender: [email-masked]

> > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to
you!
>
> I don't really like sending the capability to client automatically. That
> also means that we would receive the capability twice, once at start and
> next after issuing CAPABILITY VHOST (..).

You either need to convince people that it's ok for a client
to just try it and then fallback on failure, or the client
needs to get the information twice anyway.  By pre-announcing
we're just short circuiting one of the round trips.

I initially proposed something that utilized the error
codes of existing server to determine if it supported
arguments to CAPABILITY.

An example of that proposal when used against an existing
server would now look like:

* IMAP Server - Hello there!
C: 1 CAPABILITY VHOST (fqdn.example.com) ...
S: 1 BAD Unexpected extra arguments to Capability
C: 2 CAPABILITY
* CAPABILITY IMAP4rev1 ...
S: 2 OK Completed

I expected that over time servers would come to deal
with the added arguments (first just by swallowing them
and not returning BAD, but still responding to CAPABILITY)
and so the only "wasted bandwidth" was during the initial
introduction of the parameter, and only when new clients
were used against old servers.  Existing servers are
prepared for such "malformed" requests so I was just
taking advantage of "corerct behavior".

I, like yourself, was trying to minimize the number of
times a client had to parse a CAPABILITY response.
But people didn't like that the client didn't at least
have a method for having foreknowledge, so it forced
a round trip.

That example would now look like:

* IMAP Server - Hello there!
C: 1 CAPABILITY
S: * CAPABILITY  IMAP4rev1 ECAPABILITY ...
S: 1 OK Completed
C: 2 CAPABILITY VHOST (fqdn.example.com) ...
S: * CAPABILITY  IMAP4rev1 ECAPABILITY VHOST (fqdn.example.com) ...
S: 2 OK Completed

Which still makes the client make two round trips, but
now it has to actually pay attention to the result of
the first one just to find out if it can issue the second.
Of course, there's nothing stopping a client from doing
it the way I first proposed.  I have no reason to believe
the first proposal is "wrong" in anyway.

But let's stick to the new method.
So the client issues a CAPABILITY line to find out if it
can issue a parameterized CAPABILITY line.  Well that's
two round trips and two CAPABILITY parses.  That kinda
sucks, why don't we "preannounce" the first CAPABILITY
command that we know the client is going to have to
issue anyway and save the client at least one round trip?

If we don't pre-announce the capabilities we make the client
fetch for it.

Now these same semantics are not only related to ECAPABILITY
also AUTHENTICATE and probably others.  So the thought is
that if we are going to bother with preannouncing something
we might as well preannounce the whole capability response.
This will save all clients at least one round trip regardless
of what they are going to do.

Of course we could/should break this out into two
extensions - One is ECAPABILITY (for lack of a formal term)
and the other is "CAPABILITY ON HELLO".

If we did that, would you be satisfied that ECAPABILITY
on its own and as its own CAPABILITY term is fine, and
then talk about the merits of "CAPABILITY ON HELLO"
in a different thread?

-- Michael --

Subject: Re: Adding a parameter to CAPABILITY
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Michael Fair <[email-masked]>, [email-masked]
Organization: 
Date: 02 May 2003 00:47:22 +0300
Sender: [email-masked]

On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote:
> For better compatibility with clients that won't understand ECAPABILITY I 
> think ECAPABILITY should be a capability value itself. This means that the 
> greeting string can continue to display the CAPABILITY response code that 
> some servers now return, but would include ECAPABILITY as one its items:
> 
> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

I don't really like sending the capability to client automatically. That
also means that we would receive the capability twice, once at start and
next after issuing CAPABILITY VHOST (..).

From: "Michael Fair" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, <[email-masked]>
Subject: Re: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 14:11:13 -0700
Organization: DaClubhouse
Sender: [email-masked]

> Hi Michael,
>
> --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair
> <[email-masked]> wrote:
>
> | Any and all feedback is welcome and encouraged.
> | Especially in finding the string to put in the
> | Hello response.
>
> For better compatibility with clients that won't
> understand ECAPABILITY I think ECAPABILITY should
> be a capability value itself. This means that the
> greeting string can continue to display the
> CAPABILITY response code that some servers now
> return, but would include ECAPABILITY as one its items:
>
> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

I've got no problem with that at all. :)
I'll keep an ear open for calling it something
other than ECAPABILITY, "CLIENTCAPABILITY" has also
been suggested, I missed mentioning it earlier.

Anyone else have any other suggestions or should
we move on to actually drawing up a draft?

If we should move on to drawing up a draft, are
there any other currently proposed extensions aside
from VHOST that this new draft should supercede?

I would love to hear some feedback from more
server implementors and client writers that are
on the list as to their opinion on how this
should proceed.  What changes, if any, would help
make their lives easier and thus more likely to
add this command into their code.

-- Michael --

Date: Thu, 01 May 2003 16:35:24 -0400
From: Cyrus Daboo <[email-masked]>
To: Michael Fair <[email-masked]>, [email-masked]
Subject: Re: Adding a parameter to CAPABILITY
Sender: [email-masked]

Hi Michael,

--On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair 
<[email-masked]> wrote:

| Any and all feedback is welcome and encouraged.
| Especially in finding the string to put in the
| Hello response.

For better compatibility with clients that won't understand ECAPABILITY I 
think ECAPABILITY should be a capability value itself. This means that the 
greeting string can continue to display the CAPABILITY response code that 
some servers now return, but would include ECAPABILITY as one its items:

* OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

-- 
Cyrus Daboo

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 13:05:47 -0700
Lines: 89
Sender: [email-masked]

After much discussion about the VHOST feature
for virtualizing domains and being able to
reliably host multiple domains on a single IP.

The general consensus is that being able to reliably
host multiple domains on a single IP is useful,
using a parameter to STARTTLS, while preferred
and already supported with a STARTTLS draft
extension, is unreliable, and that any of the other
recommended solutions essentially equates adding a
parameter to CAPABILITY, finally, that if we are
going to bother adding a parameter to CAPABILITY
we might as well make it so that future
modifications of a similar type don't need another
modification to the protocol and thus a client
should be able to submit its own capability options
to the server when it makes a capability request.

This feature in general is being referred to as
a "Client CAPABILITY" line.  It's purpose is to
inform the server of any capabilities the client
has that the server may need to be informed of
(no current need has been identified for this though
there are potential ideas for its use) and to pass
parameters to the server for any capabilities
the server offers that may be modified (this is
the feature that VHOST would use).

As such, the current proposal on the table
goes along the lines of:

1) A specific string is added to the HELLO response
   to notify the client that a client capability
   parameter is supported.  The only string suggested
   as of yet is "[ECAPABILITY]" following with ESMTP.
   Other suggestions are requested.

2) A client MAY provide a CAPABILITY parameter if it
   saw the appropriate string in the HELLO response.
   The client capability should match syntax with the
   existing CAPABILITY response to prevent servers
   from having to invent new parsers.

3) The CAPABILITY response from the server MUST
   acknowledge each parameter response it understands
   to inform the client of the accepted parameters and
   their status.  Absence of a parameter in the servers
   CAPABILITY response means the server does not support
   or does not understand that particular CAPABILITY.
   Syntax errors on parameters that the server does
   understand SHOULD respond with "BAD" and give the
   appropriate reason for failure.

4) While a client capability parameter may be supported
   the rules which govern the individual options are
   defined on a per instance basis.
   For instance, with VHOST, once a client has entered
   into a TLS session or the AUTHENTICATED state, if
   the client should issue another CAPABILITY line the
   VHOST parameter SHOULD NOT be changed, and if the
   client does try and change it, the server SHOULD
   respond with "No" indicating the VHOST parameter
   has been changed and is invalid (an exception might
   be made for server administrator users).  It is
   considered a security risk to allow clients to
   jump between domains once they are in a TLS session
   or the AUTHENTICATED state.

So an example conversation might be the following (note
the server does not support LANGUAGE and so leaves it out
of its response to CAPABILITY):

S: * OK [ECAPABILITY] IMAP server ready.
C: 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB)
S: 1 OK [CAPABILITY IMAP4rev1 VHOST (fqdn.example.com) RLIST ...]
C: 2 STARTTLS
S: 2 OK
...etc...

Any and all feedback is welcome and encouraged.
Especially in finding the string to put in the
Hello response.

-- Michael --

Date: Fri, 30 May 2003 14:12:47 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New ANNOTATEMORE draft
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>     Title        : IMAP ANNOTATEMORE Extension
>     Author(s)    : C. Daboo
>     Filename    : draft-daboo-imap-annotatemore-03.txt
>     Pages        : 17
>     Date        : 2003-5-20

 From section 7:

"If a client attempts to store or retrieve a shared annotation on a 
READ-ONLY mailbox, the server MUST respond with a NO response."

Is there a reason why I shouldn't be able to fetch a shared annotation 
on a READ-ONLY mailbox?

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

Date: Wed, 21 May 2003 11:43:17 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: New ANNOTATEMORE draft
Sender: [email-masked]

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-03.txt
	Pages		: 17
	Date		: 2003-5-20
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  This document describes two 'profiles' for mailbox and
server metadata.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-daboo-imap-annotatemore-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-daboo-imap-annotatemore-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.

-- 
Cyrus Daboo

Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-07.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 21 May 2003 15:34:52 +0300
Sender: [email-masked]

>    In some cases, servers may be able to offer annotations on some
>    mailboxes and not others.  For mailboxes that cannot have
>    annotations associated with them, the server MUST return an
>    "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT
>    or EXAMINE command for that mailbox.  Clients MUST NOT attempt to
>    fetch or store annotations on any messages in a mailbox for which
>    the "ANNOTATESIZE" response was zero.

What if I want read-only annotation support? I think ANNOTATESIZE 0
should mean that client must not attept to store annotations, but it may
try fetching shared annotations.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-07.txt
Date: Wed, 21 May 2003 08:10:40 -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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-07.txt
	Pages		: 22
	Date		: 2003-5-20
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-annotate-07.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-annotate-07.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-annotate-07.txt

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

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

--OtherAccess--

--NextPart--

From: Michael Fair <[email-masked]>
Organization: DaClubhouse
To: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: Foreknowledge  versus pipelines
Date: Tue, 20 May 2003 19:07:58 -0700
Sender: [email-masked]

On Tuesday 20 May 2003 01:39 pm, Timo Sirainen wrote:
> On Tue, 2003-05-20 at 22:22, Michael Fair wrote:
> > Could we achieve the same result by having the server dump the
> > queue and then /dev/null the rest of the incoming queue data
> > and then once that's finished return a "NO" to the client
> > citing the error?
>
> Currently my server just disconnects the client if it tries to use too
> large literal+ size. I don't think it's a good idea to allow clients to
> say "hey, I'll send you 2 gigabytes of data, start reading" especially
> before logging in.

What's to stop a client from doing that now?
S: * Hello Welcome to IMAP
C: 1 a
C: 2 a
C: 3 a
.....  Repeat 2G worth .....

The result is the same - it's just less explicit about its intentions.

> How about specifying a limit for which you can use literal+? So that if
> you send less data than eg. 8192 bytes, you can safely send it, but for
> anything more you'd have to use regular literals which server can
> reject.

I'll have to read up on literal+ to understand what it does and how it behaves 
before I can really comment.  If we are going to refuse a client for too much 
data before they start sending it, then I think we should explicitly tell 
them that it's clear to send somehow.  I'm thinking a client must wait till 
it receives a response from the server which can be "+", "NO" or "BAD".

If "+" the client can send the data.  Once the number of octects specified by 
the client for the CQUEUE is reached, the buffer closes and if the buffer 
does not end in a \r\n it is a syntax error and is responded with "BAD" 
immediately.  No further data is read by the server until the CQUEUE is
finished or until a command in the queue that needs more input is reached.

> > If we fix the octet counts so that server announces a max octet
> > buffer which cannot be exceeded, and the client announces how
> > much data it is submitting, the last two octets of which must
> > be \r\n (the end of a command), would that satisfy the concerns
> > that you have over this causing problems for generic usage?
>
> No, I'm thinking there could be some more subtle problems when some of
> the commands in the group changes state in some way. My server currently
> trashes all buffered input after logging in since the client's socket is
> transferred to another process, but maybe I should fix that since it's
> not fully IMAP compliant..

The full intent of this is to allow the client to optimistically "guess" a 
valid command path to go from HELLO to AUTHENTICATED.  I expect clients might 
want to cache the command chain that worked and replay it whenever they log 
in for that account.

Each command either succeeds, or the whole process stops.  Each command is 
executed in order.  This way the client progresses through the various states 
without stopping to check the environment (unless the chain fails of course).

So this leads me to:

S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (111)
S: +
C: 3 VHOST (fqdn.example.com)
C: 4 LANGUAGE (new_lang)
C: 5 STARTTLS
C: 6 AUTHENTICATE PLAIN
C: 7 SELECT INBOX
... Rest as before but selecting the INBOX at the very end of the chain ...

And for failures:
S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (9999)
S: 2 NO Too much data

S: * Hello welcome to IMAP
C: 1 CAPABILITY
S: 1 OK CAPABILITY CQUEUE (8192)
C: 2 CQUEUE (11)
S: +
C: 3 VHOST (fqdn.example.com)
S: 2 BAD Buffer does not end on a newline
... Server then should discard everything up to the next \r\n lest 
    it choke on bad input ...

> > > > As with the GROUP proposal, as bonus points, there would
> > > > be an optional "TRANSACTION" parameter which would have
<snip>
> - etc.

Until the rest of the command has been settled on I'm removing this from the
list unless someone else would like to take a stab at clearly defining the 
semantics.  If someone does want to take it on, for the most part, it should 
be sufficient to follow SQL database semantics for this in regards to 
simoultaneous access - CQUEUE with TRANSACTION could lock all writes to the 
mail store until it completed (most likely responding with "NO Transaction in 
progress" for any write operations until the QUEUE completed.  If a command 
should fail, then the mail store should be message data and state identical 
to what it was before, and the session should be in whatever state it was in 
prior to the CQUEUE command.  

A more advanced server could parse through the command structure and build a 
list of object locks it would need prior to starting, would then lock those 
objects (or fail if it couldn't obtain such locks), and execute the commands.  
Any other client wanting to operate on other non-locked objects could be 
allowed to do so, attempting to write to a locked object should fail 
instantly to notify the client that the data is potentially about to change 
and it should fetch an update.  Reading locked objects might be a blocking 
operation until the transaction completes, or might be refused pending 
transaction completion.  I don't know exactly what all the details for the 
most useful operation behaviors would be - or even why it might be useful, so 
until there is a clearer use case and understanding of the mail store and 
session states as transactional creatures I'll withdraw it from the table.

-- Michael --

Subject: Re: Foreknowledge  versus pipelines
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 20 May 2003 23:39:00 +0300
Sender: [email-masked]

On Tue, 2003-05-20 at 22:22, Michael Fair wrote:
> Could we achieve the same result by having the server dump the 
> queue and then /dev/null the rest of the incoming queue data
> and then once that's finished return a "NO" to the client
> citing the error?

Currently my server just disconnects the client if it tries to use too
large literal+ size. I don't think it's a good idea to allow clients to
say "hey, I'll send you 2 gigabytes of data, start reading" especially
before logging in.

How about specifying a limit for which you can use literal+? So that if
you send less data than eg. 8192 bytes, you can safely send it, but for
anything more you'd have to use regular literals which server can
reject.

So:

1 cgroup {40+}
2 capability
3 starttls
4 authenticate plain
..

10 cgroup {1000000}
10 NO Too much data

> If we fix the octet counts so that server announces a max octet
> buffer which cannot be exceeded, and the client announces how
> much data it is submitting, the last two octets of which must
> be \r\n (the end of a command), would that satisfy the concerns
> that you have over this causing problems for generic usage?

No, I'm thinking there could be some more subtle problems when some of
the commands in the group changes state in some way. My server currently
trashes all buffered input after logging in since the client's socket is
transferred to another process, but maybe I should fix that since it's
not fully IMAP compliant..

> > > As with the GROUP proposal, as bonus points, there would 
> > > be an optional "TRANSACTION" parameter which would have
> > > a server revert to the same state prior to executing 
> > > the CQUEUE chain.
> > 
> > No, even if server used a database capable of transactions for storing
> > messages this would get complex.
> 
> I should have been clearer: TRANSACTION is an optional server
> implementation choice.  It is an addon to CQUEUE not part of it.
> It was never intended that any servers had to implement it.
> The only other option would be to omit the possibility entirely
> which I felt would be somewhat of an oversight.

If you specify it, you'll have to specify exactly what it does. "revert
to original state" isn't very exact. For example:

- Does any other session see the changes before transaction is complete?
(No, or it breaks really badly)

- Client must be able to revert it's own understanding of the server
state as well.

- What happens if there's external updates while processing the
transaction? Should server just not announce those (could be difficult),
or how would client know what the original state looked like? For
example you do EXPUNGE and the next command fails, server reverts the
EXPUNGE but not the few pending EXPUNGEs that weren't yet announced to
client. Does client now have any idea what sequence number is what?

- etc.

From: "Michael Fair" <[email-masked]>
To: "Timo Sirainen" <[email-masked]>, <[email-masked]>
Subject: Re: Foreknowledge  versus pipelines
Date: Tue, 20 May 2003 12:22:30 -0700
Organization: DaClubhouse
Sender: [email-masked]

> 
> On Mon, 2003-05-19 at 02:28, Michael Fair wrote:
> > S: * Hello Welcome to the IMAP server
> > S: * CAPABILITY CQUEUE STARTTLS VHOST .......
> > C: tag1 CQUEUE (4)
> > C: tag2 VHOST (fqdn.example.com)
> > C: tag3 LANGUAGE (new_lang)
> > C: tag4 STARTTLS
> > C: tag5 AUTHENTICATE PLAIN
> 
> This isn't too easy to implement. At the very least server should be
> able to abort the whole queue if it doesn't like it for some reason, for
> example because it thinks it has too much data in it.

I think that would be a fine idea.  Part of the reason I put
(4) in the CQUEUE command was to give the server the opportunity
to allocate an array of strings.  I then figured it would fill
the array and then execute the commands.  Perhaps this wasn't
the right approach.

What if the server CAPABILITY response provided a CQUEUE maxoctets 
parameter which will gave the maximum number of octets including 
the tags and \r\n that the server can store.
So the CAPABILITY response might read: CQUEUE (8192)

If that's the case, then perhaps the initial parameter to CQUEUE 
the client submits should be the number of octets the client will 
be submitting (including \r\n and tags).  So instead of CQUEUE (4)
which was 4 commands it would be "tag1 CQUEUE (97)" Which would be
everything from "tag2" to the "\r\n" of AUTHENTICATE (assuming I 
counted that right).  If any characters are multibyte characters
then those characters count as multiple octets.

If the server should find that there is too much data, the server
should dump the queue, /dev/null the rest of the incoming queue 
data (which is now countable by the number of octets) and then 
respond with "NO" giving an appropriate reason.

> Still .. it would require that server reads the data into buffer before
> processing any of it. And could there be literals in queue? That would
> mean that server has to actually parse all the commands before executing
> them. That could get tricky.
>
> Maybe a bit easier version would be to send the commands inside a
> literal so server can just read it into buffer, and it can immediately
> tell the client if there's just too much data in it (literal+ shouldn't
> be allowed with it).

I'm afraid I'm not too familiar with many IMAP commands.  The 
intent was that only single line commands could be queued.  
And the newlines would be used as command separators.  The
tags were needed to identify the individual commands in the queue
and would be treated as if they were executed without the CQUEUE
command so should be globally unique within the session.
Commands that required more than one line would be processed 
in turn and would fetch any extra lines at the time of execution.
The server would delay parsing the command until it was time to 
execute it.

If literal+ is an extra long one-liner, then I think if we used
the octet count strategy from above there'd be no reason to keep
it excluded from the list of valid commands.

I don't know that the server "immediately" telling the client
there's too much data is necessary.  It's also very probable
given how I was thinking this command would be used, that the 
client isn't paying attention to server responses at the time 
they are filling the queue.  

Could we achieve the same result by having the server dump the 
queue and then /dev/null the rest of the incoming queue data
and then once that's finished return a "NO" to the client
citing the error?

I'm picturing that the client is going to be in two modes
when it uses this command.  Mode 1, is to stuff a bunch of
commands in the queue, and then mode 2 is to get the results
of each command and interact with any conversations it has
to have to process them.

If we use the byte counters I suggested above then CQUEUE
could treat that many following bytes as literal data stuffing
it in a single buffer and then reading from it.

> Still, I'm not sure if this is a good idea. As limited in above example
> it would work, but as a more generic feature it would just cause
> problems.

The primary motivation for this was to reduce round trips with
the server during the log in process when the overall consensus 
is that many smaller commands is better than a generic big one.
The discussion saw parallels to the MULTIAPPEND discussion
(which I wasn't around for) and it seemed that an alternative
that might have worked there could also work here.

I had already worked on several commands that were very similar
in nature to this proposal and figured that there was probably
no escaping it.  So the only question was is this new command
only valid in the non-AUTHENTICATED state, or is it something
that could be genericly useful?  I'd tend towards the more
generic mostly because I'm just bent that way, but if this only
ended up to server the log in process it will have met the 
original design goals I had in mind.

If we fix the octet counts so that server announces a max octet
buffer which cannot be exceeded, and the client announces how
much data it is submitting, the last two octets of which must
be \r\n (the end of a command), would that satisfy the concerns
that you have over this causing problems for generic usage?

> > As with the GROUP proposal, as bonus points, there would 
> > be an optional "TRANSACTION" parameter which would have
> > a server revert to the same state prior to executing 
> > the CQUEUE chain.
> 
> No, even if server used a database capable of transactions for storing
> messages this would get complex.

I should have been clearer: TRANSACTION is an optional server
implementation choice.  It is an addon to CQUEUE not part of it.
It was never intended that any servers had to implement it.
The only other option would be to omit the possibility entirely
which I felt would be somewhat of an oversight.

I also wasn't clear enough on this when I originally submitted it,
not only would the server need to support "TRANSACTION" but the 
client would also need to request that it wanted transaction 
semantics.  I only saw this becoming popular in the event there
developed an important use for it and the server challenges of
implementing it were overcome (which they would be if there was 
an important enough use for it).

Thanks for responding!
-- Michael --

Subject: Re: Foreknowledge  versus pipelines
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 20 May 2003 20:14:04 +0300
Sender: [email-masked]

On Mon, 2003-05-19 at 02:28, Michael Fair wrote:
> S: * Hello Welcome to the IMAP server
> S: * CAPABILITY CQUEUE STARTTLS VHOST .......
> C: tag1 CQUEUE (4)
> C: tag2 VHOST (fqdn.example.com)
> C: tag3 LANGUAGE (new_lang)
> C: tag4 STARTTLS
> C: tag5 AUTHENTICATE PLAIN

This isn't too easy to implement. At the very least server should be
able to abort the whole queue if it doesn't like it for some reason, for
example because it thinks it has too much data in it.

Still .. it would require that server reads the data into buffer before
processing any of it. And could there be literals in queue? That would
mean that server has to actually parse all the commands before executing
them. That could get tricky.

Maybe a bit easier version would be to send the commands inside a
literal so server can just read it into buffer, and it can immediately
tell the client if there's just too much data in it (literal+ shouldn't
be allowed with it).

Still, I'm not sure if this is a good idea. As limited in above example
it would work, but as a more generic feature it would just cause
problems.

> As with the GROUP proposal, as bonus points, there would 
> be an optional "TRANSACTION" parameter which would have
> a server revert to the same state prior to executing 
> the CQUEUE chain.

No, even if server used a database capable of transactions for storing
messages this would get complex.

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Subject: Foreknowledge  versus pipelines
Date: Sun, 18 May 2003 16:28:45 -0700
Organization: DaClubhouse
Sender: [email-masked]

Greetings all,

So the latest developments on trying to harmonize
on a design for reducing client side round trips
while allowing for new pre-AUTH commands like 
LANGUAGE and VHOST has come down to making a 
decision between client foreknowledge that a 
particular command is actually going to be valid 
when it is executed and allowing a client to chain 
a series of commands together that the server 
will execute in sequence.

After looking at it my self and talking it over 
with a couple others it has become more and more 
clear that the preferred approach is pipelining
or command chaining.

The LANGUAGE is already in implementation that
expects it to be its own command, and the VHOST
draft is also written with the expectation that
it be its own command.  The obvious downside to
this is that a client has to issue these each
as separate commands and for commands that can
change the CAPABILITY response is forced to wait
until that command is complete before moving on.

This proliferation of commands demands an efficient
way for clients to execute the series of them and
to ensure they get executed in the proper order.

Chris Newman shared with me that while discussing
the MULTIAPPEND command he suggested a GROUP command
that would allow a client to specify a series of 
commands in order.

In keeping with that theme I propose a command called
"CQUEUE" which would allow the client to create a 
"Command Queue" which would execute the commands in
the queue in sequence and terminate at the first 
failure (defined as a "NO" or "BAD" response).

Commands would be held up for execution until each
prior command had finished executing.  As a result
the command issued need not be valid in the current
CAPBILITY context.

The dialog would look something like this:

S: * Hello Welcome to the IMAP server
S: * CAPABILITY CQUEUE STARTTLS VHOST .......
C: tag1 CQUEUE (4)
C: tag2 VHOST (fqdn.example.com)
C: tag3 LANGUAGE (new_lang)
C: tag4 STARTTLS
C: tag5 AUTHENTICATE PLAIN
C: 
S: tag2 OK VHOST (fqdn.example.com)
S: * CAPABILITY ... new capability after VHOST ...
S: tag3 OK LANGUAGE (new_lang)
S: tag4 OK BEGIN TLS
<do the TLS negotation with the client>
S: tag4 OK STARTTLS successful
S: * CAPABILITY ... new capability after STARTTLS ...
S: +
<have the AUTHENTICATE conversation>
S: tag5 OK AUTHENTICATE successful
S: * CAPABILITY ... new capability after AUTHENTICATE ...
S: tag1 OK CQUEUE successful

I've proposed changing the name to CQUEUE from GROUP
because I felt a "Command Queue" was a bit more 
descriptive than a "Group of commands".

The primary security risk preTLS is that any command
issued goes in the clear.  As a result it is forbidden
for a client to execute a LOGIN in this manner if the
client is going to attempt to establish a TLS session.

As for the AUTHENTICATE command, that is different that
the only revealed information is what method the client
was going to request be attempted first.  Knowing which 
authentication method a client was going to request post 
TLS does not reveal any information that compromises 
the security of the TLS session or the client's data.

The client can and SHOULD monitor the execution of the
command queue as the server announces its progress.
If the command queue fails then the tag assigned to the
failed command MUST be in the "NO" response to CQUEUE
command in addition to the "NO" or "BAD" response.

As with the GROUP proposal, as bonus points, there would 
be an optional "TRANSACTION" parameter which would have
a server revert to the same state prior to executing 
the CQUEUE chain.

-- Michael --

Date: Sat, 17 May 2003 17:44:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Pete Resnick wrote:

> I've been reminded to start early on figuring out what's going on for
> the next IETF meeting, so let's do that.
>
> Document editors: Please provide to the list the status of your
> documents. Are there open issues that will need to be discussed in
> Vienna?
>
> Others: Are there items that you think need to be discussed in
> Vienna? Do remember that LEMONADE-related items should be discussed
> over there.
>
> I will be in Vienna either way. Let's figure out now whether we need a meeting.

I will be in Vienna anyway.

I should send an update revision of CONDSTORE in a week or so. Than I have some
SASL documents I have to work, but I am planning to send ACL2 update before Vienna.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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

Date: Sat, 17 May 2003 12:13:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Sender: [email-masked]

Mark Crispin wrote:

> ...

> My understanding of our status is:
>
> I) CHARTER EXTENSIONS
>
> SORT/THREAD is done, but will need to be blocked on I18N since it makes a
> normative reference to it.
>
> I believe that the remaining documents that we need to complete to fufill
> the charter are:
>
>         ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N
>
> II) NON-CHARTER EXTENSIONS.
>
> We also are considering:
>
>         LISTEXT
>
> and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired
> drafts:
>
>         QUOTA, UNSELECT
>
> I decided not to oppose UNSELECT any more; indeed, I recently implemented
> it in my server.  Cyrus server has it too.  So let's do a quick last call
> and get it published.

I will try to publish the UNSELECT document shortly.

> I vote to proceed on LISTEXT and punt on the other non-charter proposals.

I agree. QUOTA will most likely be taken by LEMONADE people anyway.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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

Date: Fri, 16 May 2003 04:39:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LAST CALL: SORT AND THREAD EXTENSION
Sender: [email-masked]

As we agreed in Atlanta, now that the IMAP i18n document is an I-D this is
a last call for draft-ietf-imapext-sort-13.txt prior to it being submitted
to the IESG.

-- Mark --

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-13.txt
Date: Fri, 16 May 2003 07:22:23 -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 - SORT AND THREAD 
                          EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-13.txt
	Pages		: 19
	Date		: 2003-5-15
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.
A server which supports the base-level SORT extension indicates this
with a capability name which starts with 'SORT'.  Future,
upwards-compatible extensions to the SORT extension will all start
with 'SORT', indicating support for this base level.
A server which supports the THREAD extension indicates this with one
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-sort-13.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-13.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-sort-13.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-sort-13.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 14 May 2003 15:41:29 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
To: Timo Sirainen <[email-masked]>, [email-masked]
Sender: [email-masked]

begin  quotation by Timo Sirainen on 2003/5/14 18:13 +0300:
> Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is
> a bit badly designed. "If there's one language, that's what got
> selected. if there's multiple ones, nothing was selected but you should
> select one of them". Kind of messy.

I agree that the design of the LANGUAGE reply is messy.  But it is also
unambiguous as defined in the spec, so I don't see a reason to change it.

> Why not have work like COMPARATOR reply?

Because they were designed by different people.

> Or maybe give the selected language as resp-text-code in tagged
> OK reply?

That would be inconsistent with other IMAP commands that adjust server state.
So I don't see it as better from an aesthetic point of view.

> I think he means something like:
> 
> 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP
> Extensions") 1 OK
> 2 LIST (ANNOTATION ("alias")) "" %
> * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/"
> "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions"))))
> "/" "ietf-imapext" 2 OK
> 
> INBOX and maybe some other site global mailbox names could be predefined
> for multiple languages which would be used after client has selected
> language.

So maybe the ANNOTATEMORE extension should define a namespace for localized
mailbox names?  Sounds reasonable to me.

> Looks like LISTEXT and ANNOTATEMORE don't play together currently.
> Should they? I'd like the possibility to do above.

I concur.

> Other issues in the draft:
> 
> "Clients MUST re-issue the LANGUAGE command once a security layer is
> active" is mentioned only in "security considerations. I think it should
> be mentioned in section 3.2 also.
> 
> You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does
> sorting by subject.

OK.  Will fix these two in the next version.

                - Chris

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Chris Newman" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Wed, 14 May 2003 12:51:13 -0700
Organization: DaClubhouse
Sender: [email-masked]

> On Wed, 14 May 2003, Michael Fair wrote:
> > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)
>
> This is a contrived example.
>
> It's impossible to pipeline anything after STARTTLS.  In fact, it's
> impossible to even think about transmitting anything after STARTTLS, since
> you need to do the key exchange negotiation before you have the physical
> capability of transmitting the AUTHENTICATE.

Sorry I was confusing the existing mechansims with the work I
was doing on ECAPABILITY which was attempting to reduce round
trips by asking the client for information as it needed it
(thus STARTTLS would negotiate and once completed the server
 would immediately begin the AUTH conversation (lest the method
 requested wasn't supported and would therefore stop, requiring
 the client to issue a CAPABILTIY to find out what methods
 were supported).

Even barring that ability, just drop the AUTH command off the
end and the example still holds.

The point is that pipelining and foreknowledge are mutually
exclusive for most commands prior to AUTH because most of
the important pre-auth commands change the CAPABILITY response.
As a result, a client must issue a command, wait for the response,
get the new capability list, issue the next command, wait, issue
the next command, wait.

A more detailed state progress of the above example as currently
implemented by the proposed solutions:

1) Client shows up at server gets hello and requests CAPABILITY
   server sends LANGUAGE VHOST (but not STARTTLS, AUTH, or LOGIN)
2) Client issues the LANGUAGE command
3) Client issues the VHOST command
***** Client waits *****
4) Client gets new CAPABILTIY and the server now issues
   LANGUAGE VHOST STARTTLS LOGIN and AUTH (but not AUTH plain)
5) Client issues STARTTLS and does the negotation
***** Client waits *****
6) Client gets the new CAPABILTIY and the server now issues
   LANGUAGE VHOST STARTTLS LOGIN and AUTH including AUTH plain
7) Client issues AUTH using the plain mechanism
***** Client waits *****
8) Client gets the new CAPABILTIY and is now ready to begin
   the real IMAP session work

Same example with the method I was envisioning:
1) Client shows up at server gets hello
2) Client issues a new version of PIPELINE (with ordering
   and negotiation support) with the following chain:
LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)
***** Client watches responses as the server executes each *****
***** Client waits for BAD, NO, or STARTTLS *****
3) Client does STARTTLS negotiation
***** Client waits for BAD, NO, or AUTH negotiation *****

If the client receives BAD or NO it knows what state it
is in because the server issued and OK for every command
that succeeded.  Once an error occurs in the command chain
processing of the chain stops.

-- Michael --

Date: Wed, 14 May 2003 12:28:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 May 2003, Michael Fair wrote:
> LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)

This is a contrived example.

It's impossible to pipeline anything after STARTTLS.  In fact, it's
impossible to even think about transmitting anything after STARTTLS, since
you need to do the key exchange negotiation before you have the physical
capability of transmitting the AUTHENTICATE.

I'm finding it very difficult to read your messages.  Could you please get
to the point in a more consise fashion?

-- Mark --

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

Date: Wed, 14 May 2003 12:28:19 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

I can't wade through your long message to answer it point-by-point, but
here is a pedagogical explanation:

LEMONADE has identified a need to send messages containing content from a
mailbox in an IMAP server.  It is costly, especially for embedded devices,
to fetch the content from an IMAP server just to send it back out to an
SMTP server.

On the other hand, if the message submission server is not co-located with
the IMAP server, then the submission server must have full IMAP access to
the user's account on the IMAP server.  This is perceived as a security
risk.

Consequently, it was proposed to use an IMAP server as a mesasge
submission agent, by submitting the message with "include such-and-such
text from such-and-such mailbox" pointers, which the IMAP server will
acquire locally.

As a counter proposal, I suggest a means by which an IMAP client can
create a limited access token, which can access only the necessary data
but not any other data.  This limited access token can be used by the
message submission server to obtain the data from the IMAP server without
giving the message submission server access to any other user data.

This also permits the message submission server to access data from
multiple IMAP servers.  Furthermore, it does not create a situation in
which IMAP duplicates the functionality of other protocols.

-- Mark --

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

From: "Michael Fair" <[email-masked]>
To: "Chris Newman" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Wed, 14 May 2003 11:23:51 -0700
Organization: DaClubhouse
Sender: [email-masked]

> begin quotation by Michael Fair on 2003/5/13 11:45 -0700:
> > Is there anything else anyone else saw that seems to make
> > this whole client side CAPABILITY approach to items like
> > VHOST and LANGUAGE (and perhaps a CHARSET could be added
> > to the list for UTF-8 support?) a bad idea?
>
> We discussed the issue of client capabilities at the informal
> IMAPEXT BOF at
> the last IETF and there was a rough consensus in the room (of about 20
> IMAP developers many of whom write code) which opposed the idea of a
> combined client capability mechanism.  The rough consensus of the
> room appeared to favor separate commands which could be pipelined
> rather than a combined command.  Now the mailing list can override
> that consensus, but I'd need to see stronger support than I've seen
> to date.

No one prior to you had ever mentioned that.  Wish I would have known
would have saved me some trouble. :)

Creating a command pipeline works for me.  I actually like that
even more, but it seems to break with what a few ppl have said
to me earlier in that they really don't like the idea of a client
trying a command to find out if it will work or not.  The general
premise is that a client should always have foreknowledge that
the command they want to use is valid.

But there's a problem with this, since pretty much every commonly
used command prior to authenticating has the potential to
change the "environment" (read CAPABILITY response) then
pipelining and foreknowledge are somewhat mutually exclusive
in that using one denies the other.

As an example, a client wants to execute:
LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain)

Even though this might be a very valid sequence there's no way
for a client to know whether or not this will work without stopping
at each point and waiting for the response.  STARTTLS might not
be available till after VHOST and AUTH plain might further not
be available until after STARTTLS.

I also understood that servers can reorder commands so depending
on the order executed the above means different things and it's
success rate differs depending on the order executed.

I personally prefer pipelining much more than foreknowledge on
principal because the errors generated by usage of this nature
uses a very minor number of resources in comparison to the
possible efficiency gains and 9 times out of 10 the client is
just checking to make sure the server does something that
already has a more than reasonable chance at succeeding.

The only con is that it demands proper failure behavior which
should be, but is not always what's out there.  However,
protecting clients that don't check return codes and servers
that don't generate them by not implementing a feature that
could give trmendous efficiency gains for those that do the
proper thing seems like it's asking for trouble.

Since the commands will succeed the majority of the time, it
seems wasteful to cause the login process to be longer just
for a psuedo-gaurantee that it will succeed.  This is further
compounded by things admins can do to tain their environmnent.
Clients might be able to be configured for, or discover
and remember, success "paths" for the servers they access and
not be forced to stop and wait at each step every login.

If clients/servers all do some basic error checking then
pipelining would simply trip over the error codes and the
clients can issue the proper commands to get the info to
determine how to proceed.  Of course I believe that the
client would need a way to specify the order in which the
commands get executed (lest the command fail otherwise).

I can see the merits of both approaches, but it seems that
the consensus is that reducing round trips is important.
The only way I see that happening is by giving up the notion
that a client should always have foreknowledge that the
commands they are issuing are valid when it comes to being
able to pipeline commands.  Instead, it shoud be that a client
can try an optimistic pipeline expecting a chain to succeed
and the pipeline should stop executing at the first failure.

Assuming that people can live with that, I think the
multiple commands with a pipeline provision is the best
route as well.

> In addition, there is deployed running code for the LANGUAGE extension
> (implemented to the previous draft).  As a result I am opposed to
aesthetic
> changes to the LANGUAGE extension as documented.  Proposed changes need to
have
> a substantive technical justification.

The only technical justification was discussed above.

> > 2) In specific response to the LANGUAGE feature set as
> > described, I noticed it is missing in-band administration
> > for assigning the various LANGUAGE translations of folders.
> >
> > 3) Could this be extended to allow all folders to be
> > represented in multiple languages by way of some kind
> > of "ALIAS" command that could install a language alias
> > for folders?  This would probably require the equivalent
> > of a RENAME ACL.  This would anticipate a resolution
> > to the lack of character set choice currently present.
> > (For instance via a client capability mentioned above.)
>
> Please make a concrete proposal if you want to discuss these
> issues.  I'm not sure exactly what you're asking so it would
> be easier to discuss if I could see something concrete.
>
> > 4) Since languages are somewhat tied to character sets,
>
> The selected character set is always UTF-8, so there is no issue.

I was basing the character set issues off of section 5.2.
Ok so 2,3 and 4 were all related, and I might be generalizing
a feature that's not actually in the draft.

Timo's SETANNOTATION example of creating aliases for INBOX and
ietf-imapext folders were an example of how this might be used
but I wasn't expecting it to be used to create aliases in the
same language (though I think that would be useful).  Further,
the only folders that can currently be "localized" are the
folders in NAMESPACE.  There might be a technical reason for
that.  What I was envisioning was a way to name any mailbox in
many languages by assigning several language specific aliases.

This was primarily to facilitate "Shared Folders" in organizations
where people who use multiple languages share the same folder.
For instance, the folder "Technical Support" would be a general
box for incoming issues in multiple languages.  The support staff
reading this mailbox speak different languages, and as a result
would like the "Technical Support" folder to display its name
in their native language.  If they could attach a language
specific alias for the foldername, they could do this.

This would also satisfy the method by which namespace translations
would be set.  They would be treated just like any other folder
for the purpose of setting the translation to begin with.

Secondarily, if assigning aliases to arbitrary folders is
not technically feasible for some reason, then there should
still be a defined method to set the aliases for the folders
returned by NAMESPACE.  While the current draft describes how
the server should format and respond to a client to provide
the NAMESPACE response with translations, it doesn't specify
any method to set those translations in the first place.
This may just be a "server must be preconfigured" thing, but
it seems to me that there should be an IMAP command for this.

I do not feel the slightest bit qualified to recommend a
method to set the translations.  Timo's SETANNOTATION
seemed like a decent enough approach however it would
require the addition of a language parameter.

Which brings up another question, are the language names
going to support the localized variants like en_US and fr_CA?
If so, does it need any special mentioning?  For instance a
phrase like "localized variants of a language if not explicity
supported may match on either a non-localized version of the
same language or if that's not available, then another variant
of the same language.  If there are no variants of the language
supported by the server (localized or not) then the match
SHOULD fail."  I don't know if it really matters, but I expect
it'll come up sooner or later.

-- Michael --

Date: Wed, 14 May 2003 11:16:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Sender: [email-masked]

Hi Chris,

--On Tuesday, May 13, 2003 3:09 PM -0700 Chris Newman 
<[email-masked]> wrote:

| So I am now willing to see SORT and THREAD move forward without VIEW
| despite my scalability concerns.  Given how busy and resource limited the
| IMAP community appears to be at the moment, I further propose we drop the
| VIEW command from the list of WG deliverables we must complete prior to
| WG closure (but let's not bother changing the charter until we've
| finished the other deliverables).

I fully agree with this position.

-- 
Cyrus Daboo

Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 14 May 2003 18:13:51 +0300
Sender: [email-masked]

On Tue, 2003-05-13 at 23:57, Chris Newman wrote:
> In addition, there is deployed running code for the LANGUAGE extension
> (implemented to the previous draft).  As a result I am opposed to aesthetic
> changes to the LANGUAGE extension as documented.  Proposed changes need to have
> a substantive technical justification.

Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is
a bit badly designed. "If there's one language, that's what got
selected. if there's multiple ones, nothing was selected but you should
select one of them". Kind of messy. Why not have work like COMPARATOR
reply? Or maybe give the selected language as resp-text-code in tagged
OK reply?

> > 2) In specific response to the LANGUAGE feature set as
> > described, I noticed it is missing in-band administration
> > for assigning the various LANGUAGE translations of folders.
> >
> > 3) Could this be extended to allow all folders to be
> > represented in multiple languages by way of some kind
> > of "ALIAS" command that could install a language alias
> > for folders?  This would probably require the equivalent
> > of a RENAME ACL.  This would anticipate a resolution
> > to the lack of character set choice currently present.
> > (For instance via a client capability mentioned above.)
> 
> Please make a concrete proposal if you want to discuss these issues.  I'm not
> sure exactly what you're asking so it would be easier to discuss if I could see
> something concrete.

I think he means something like:

1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP Extensions")
1 OK
2 LIST (ANNOTATION ("alias")) "" %
* LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" "INBOX"
* LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) "/" "ietf-imapext"
2 OK

INBOX and maybe some other site global mailbox names could be predefined
for multiple languages which would be used after client has selected
language.

Looks like LISTEXT and ANNOTATEMORE don't play together currently.
Should they? I'd like the possibility to do above.

Other issues in the draft:

"Clients MUST re-issue the LANGUAGE command once a security layer is
active" is mentioned only in "security considerations. I think it should
be mentioned in section 3.2 also.

You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does
sorting by subject.

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Vienna
Date: Tue, 13 May 2003 22:09:54 -0700
Organization: DaClubhouse
Sender: [email-masked]

> 2) LEMONADE.
>
> LEMONADE clearly identified a need for message submission that does not
> require downloading from IMAP server; however, doing submission in IMAP is
> a mistake.  I'd rather not argue the reasons why in email; it'll
> just waste everybody's time.
>
> Instead, let's come up with an alternative so there is a choice that can
> be made.  Right now, there is no choice.
>
> I suggest a command, valid when not logged in, that will fetch a
> particular message or portion of message.  Thus, the argument to the
> command has to carry authentication of some kind; the key is that this is
> *not* the user's authentication but rather some special authentication
> that is specific to that message or portion of a message.
>
> Desirable authentication forms: use-once, anonymous, use only by certain
> entity, time-limited (e.g. "expires in 5 minutes").
>
> Could be a SASL mechanism, since SASL has the framework; ultimately
> returning a NO so it can be done multiple times in one IMAP connection.
>
> Must be expressable in an IMAP URL; the URL must carry the authentication
> (possibly also with a client-supplied token).
>
> The idea here is that the MSA is given a message with various IMAP URLs
> inserted.  The MSA resolves the URL and fetches the data from the server
> (or servers -- an advantage of doing it this way).
>
> We need a command for an IMAP client to create these things, e.g. "give me
> a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
> 12383 from my INBOX".

Please correct me if I'm wrong, let me see if I can
recap what you are proposing since I've gotten confused
about what seems to be mixed or at least unclarified
usage of the terms submission, client, and server.

1) It is inappropriate to make the IMAP server the middle man
   for transporting messages.  The client should have a method
   of requesting data directly from foriegn servers
   (aka "message submission that does not require downloading
    from IMAP server")?
   You chose not to waste people's time with the details of
   an explanation.  So you chose to propose a new IMAP command
   so we can compare and choose.

2) This new command is to provide a way for an end user client
   to tell an IMAP server to fetch arbirtrary message parts with
   authentication.  And that relates to message submission because
   the server is to fetch the data from the remote server and
   store the retrieved data as part of the message in the local
   mail store?  Or this command is intended to be issued by remote
   servers and/or clients who are trying to "pick up" the message
   parts from the current server?
   Or this has nothing to do with message submission and is about
   an end user client getting fast access to a separate IP connection
   (whether or its own use or some other agent's use) through which
   to transfer the data across with?

   It's not clear to me whether the ultimate intended recipient
   of this command is the IMAP server, the end user client, or some
   other remote service that was told to pick up the data.

You then described the authentication requirements.

3) You then concluded with describing the general idea as the
   MSA gets handed a message with a bunch of URLs and goes off
   to do its thing.  But I'm not clear on who the MSA is being
   an agent of.  Given your example it seems that intended
   destination is an end user client who already as a session
   with the current server and that the definition of "submission"
   is actually a transfer from server space to end user space
   rather than the user space submitting to server space.
   (I use server space as loose term to refer to the collection
    of servers hosting the message data, and user space as the
    collection of clients being used to view it)

I have not been following LEMONADE to really get what the current
intended framework looks like.  So it might be that I'm just missing
some background info that I haven't read yet.

Unfortunately, without clarity on exactly what the envisioned
framework is I am having a hard time picturing the overall use
and goal here.  I might also be having a hard time because I
have a general definition of submission as "moving away from
the source", of "uploading" as moving away from the current
active end user, and of "downloading" as moving to the active
service.  I just can't clearly tell what the various active
objects in your description are and when they are being active.

If the ultimate goal here to provide an end user client with
a URL so that the end user client (or local agent) can open
up another connection to the same server and quickly access
the data, then I'd think simply providing a method for doing
a "FASTAUTH" token which would at most need to renegotiate TLS
to establish the same context as the initial session is all
that would be required because then the new session can issue
the same IMAP commands the other could.
But that would leave the heavy lifting "in IMAP" which
you don't think will work.  (Because the connecting agent may
not know any IMAP over and above submitting this command?)

Further, if the purpose is really just to give other
applications on the same client machine access to the
data,  then why not have the client act as a relay between
the IMAP server and the final application.  It could
easily do this by opening a port bound to the 127.0.0.1
interface and then causing whatever Agent to connect
to that loopback port while the IMAP client then transferred
the data across via IMAP.  This allows the IMAP client to
cache the message part and provide the data to the external
application at the same time.  It further supplies a
methodology for the same dat to be viewed by the end user
multiple times without transferring from the server each time.
This method doesn't work so well for real time protocols.
Those will probably have to be handled differently unless
the server and client learn to speak RTSP.

If the purpose is to allow clients to request URLs that
are to be issued to a server other than the one the client
is talking to at the moment then I think I understand
what you're trying to accomplish.  The current server
has a message whose parts are stored in many locations,
the client wants to access these parts and therefore
requests a token from the current server to fetch them.
The questions I have then are, is it expected that all
the remote servers are IMAP servers, or are they arbitrary
protocols?  Assuming IMAP its various IMAP servers involved
then are they preaware of each other's existence?  Can the
servers share a secret between each other for generating
the URLs (perhaps PKI based?)?

If the purpose is actually to enable clients to upload data
(aka submit new data to the server) then I'm having a hard
time comprehending the client requesting a cookie to fetch
the message part.

Finally if I'm way off base on all of these, and you really
just need a simple command to fetch data, then I suggest the
command mimic the HTTP protocol (with recent extensions) as
closely as possible to leverage as much existing work and
mind share done in this area as possible (unless of course
there is some technical reason that makes this impractical.

Sorry for the long email but I just wanted to be clear about
what the vaious confusions were.

Thank you,
-- Michael --

Date: Tue, 13 May 2003 16:59:55 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SORT, THREAD and VIEW/WINDOW
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 13 May 2003, Chris Newman wrote:
> So I am now willing to see SORT and THREAD move forward without VIEW
> despite my scalability concerns.  Given how busy and resource limited
> the IMAP community appears to be at the moment, I further propose we
> drop the VIEW command from the list of WG deliverables we must complete
> prior to WG closure (but let's not bother changing the charter until
> we've finished the other deliverables).

Thank you.

My understanding of our status is:

I) CHARTER EXTENSIONS

SORT/THREAD is done, but will need to be blocked on I18N since it makes a
normative reference to it.

I believe that the remaining documents that we need to complete to fufill
the charter are:

	ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N

II) NON-CHARTER EXTENSIONS.

We also are considering:

	LISTEXT

and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired
drafts:

	QUOTA, UNSELECT

I decided not to oppose UNSELECT any more; indeed, I recently implemented
it in my server.  Cyrus server has it too.  So let's do a quick last call
and get it published.

I vote to proceed on LISTEXT and punt on the other non-charter proposals.

-- Mark --

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

Date: Tue, 13 May 2003 15:09:15 -0700
From: Chris Newman <[email-masked]>
Subject: SORT, THREAD and VIEW/WINDOW
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

There is a scalability problem with the design of SORT and THREAD because their
performance and bandwidth consumption depends on the number of messages in the
mailbox.  As a result of this problem, I held the position that we need to hold
up SORT and THREAD until the VIEW command is ready to move forward on the
standards track at the same time.

After going through a number of revisions on VIEW and WINDOW proposals with
Cyrus, my position has changed slightly.  I now recognize that the VIEW command
(or similar mechanism) would introduce significant complexity and that
complexity may exceed the benefit it provides.  In particular, the majority of
users may be satisfied to keep the size of the mailboxes on which they apply
SORT and THREAD to some reasonable limit (e.g., less than 10,000 messages) in
order to get acceptable performance.  Scalable servers might cache SORT and
THREAD results so the computation cost is minimized and perhaps bandwidth is
increasing fast enough that it isn't a concern.

So I am now willing to see SORT and THREAD move forward without VIEW despite my
scalability concerns.  Given how busy and resource limited the IMAP community
appears to be at the moment, I further propose we drop the VIEW command from
the list of WG deliverables we must complete prior to WG closure (but let's not
bother changing the charter until we've finished the other deliverables).

                - Chris

Date: Tue, 13 May 2003 13:57:04 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
To: Michael Fair <[email-masked]>, [email-masked]
Sender: [email-masked]

begin quotation by Michael Fair on 2003/5/13 11:45 -0700:
> Four things:
> 
> 1) Lately there's been talk of moving commands like these
> into a client CAPABILITY announcement string.  The command
> has been proposed as a way for the client to:
> 
> A) Announce capabilities it has that the server
>    might be able to do something special with,
> and
> B) Set options to server capabilities that impact the
>    behavior of the session
> 
> The two major candidates in most examples so far have
> been VHOST and LANGUAGE.  I didn't see anything requested
> here that would preclude LANGUAGE from being assigned
> in that manner.  The only "special case" I saw is that
> any client issuing a CAPABILITY with a LANGUAGE option
> MUST be prepared to receive an untagged NAMESPACE response
> as one of the responses to CAPABILITY.
> 
> Is there anything else anyone else saw that seems to make
> this whole client side CAPABILITY approach to items like
> VHOST and LANGUAGE (and perhaps a CHARSET could be added
> to the list for UTF-8 support?) a bad idea?

We discussed the issue of client capabilities at the informal IMAPEXT BOF at
the last IETF and there was a rough consensus in the room (of about 20 IMAP
developers many of whom write code) which opposed the idea of a combined client
capability mechanism.  The rough consensus of the room appeared to favor
separate commands which could be pipelined rather than a combined command.  Now
the mailing list can override that consensus, but I'd need to see stronger
support than I've seen to date.

In addition, there is deployed running code for the LANGUAGE extension
(implemented to the previous draft).  As a result I am opposed to aesthetic
changes to the LANGUAGE extension as documented.  Proposed changes need to have
a substantive technical justification.

> 2) In specific response to the LANGUAGE feature set as
> described, I noticed it is missing in-band administration
> for assigning the various LANGUAGE translations of folders.
>
> 3) Could this be extended to allow all folders to be
> represented in multiple languages by way of some kind
> of "ALIAS" command that could install a language alias
> for folders?  This would probably require the equivalent
> of a RENAME ACL.  This would anticipate a resolution
> to the lack of character set choice currently present.
> (For instance via a client capability mentioned above.)

Please make a concrete proposal if you want to discuss these issues.  I'm not
sure exactly what you're asking so it would be easier to discuss if I could see
something concrete.

> 4) Since languages are somewhat tied to character sets,
> it seems logical that in response to the LANGUAGE command
> aside from the language selected the character set used
> by the server to display that language should also be
> announced shouldn't it?  I've done no internationalization
> work so I'm not sure how you get two machines to align
> on a character set implicity through just a language name.

The selected character set is always UTF-8, so there is no issue.

                - Chris

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Tue, 13 May 2003 11:45:45 -0700
Organization: DaClubhouse
Sender: [email-masked]

Four things:

1) Lately there's been talk of moving commands like these
into a client CAPABILITY announcement string.  The command
has been proposed as a way for the client to:

A) Announce capabilities it has that the server
   might be able to do something special with,
and
B) Set options to server capabilities that impact the
   behavior of the session

The two major candidates in most examples so far have
been VHOST and LANGUAGE.  I didn't see anything requested
here that would preclude LANGUAGE from being assigned
in that manner.  The only "special case" I saw is that
any client issuing a CAPABILITY with a LANGUAGE option
MUST be prepared to receive an untagged NAMESPACE response
as one of the responses to CAPABILITY.

Is there anything else anyone else saw that seems to make
this whole client side CAPABILITY approach to items like
VHOST and LANGUAGE (and perhaps a CHARSET could be added
to the list for UTF-8 support?) a bad idea?

2) In specific response to the LANGUAGE feature set as
described, I noticed it is missing in-band administration
for assigning the various LANGUAGE translations of folders.

3) Could this be extended to allow all folders to be
represented in multiple languages by way of some kind
of "ALIAS" command that could install a language alias
for folders?  This would probably require the equivalent
of a RENAME ACL.  This would anticipate a resolution
to the lack of character set choice currently present.
(For instance via a client capability mentioned above.)

4) Since languages are somewhat tied to character sets,
it seems logical that in response to the LANGUAGE command
aside from the language selected the character set used
by the server to display that language should also be
announced shouldn't it?  I've done no internationalization
work so I'm not sure how you get two machines to align
on a character set implicity through just a language name.

-- Michael --

----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
Sent: Tuesday, May 13, 2003 5:00 AM
Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Internet Message Access Protocol
Extension Working Group of the IETF.
>
> Title : Internet Message Access Protocol Internationalization
> Author(s) : C. Newman
> Filename : draft-ietf-imapext-i18n-00.txt
> Pages : 18
> Date : 2003-5-12
>
> Internet Message Access Protocol (IMAP) version 4rev1 has basic
> support for non-ASCII characters in mailbox names and search
> substrings.  It also supports non-ASCII message headers and content
> encoded as specified by Multipurpose Internet Mail Extensions (MIME).
> This specification defines a collection of IMAP extensions which
> improve international support including comparator negotiation for
> search, sort and thread, language negotiation for international error
> text, and translations for namespace prefixes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> 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-i18n-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-ietf-imapext-i18n-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.
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt
Date: Tue, 13 May 2003 08:00:15 -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 Internationalization
	Author(s)	: C. Newman
	Filename	: draft-ietf-imapext-i18n-00.txt
	Pages		: 18
	Date		: 2003-5-12
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions (MIME).
This specification defines a collection of IMAP extensions which
improve international support including comparator negotiation for
search, sort and thread, language negotiation for international error
text, and translations for namespace prefixes.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-i18n-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-ietf-imapext-i18n-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-00.txt

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

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

--OtherAccess--

--NextPart--

To: Mark Crispin <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
From: Simon Josefsson <[email-masked]>
Date: Tue, 06 May 2003 23:56:43 +0200
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:

> I suggest a command, valid when not logged in, that will fetch a
> particular message or portion of message.  Thus, the argument to the
> command has to carry authentication of some kind; the key is that this is
> *not* the user's authentication but rather some special authentication
> that is specific to that message or portion of a message.
>
> Desirable authentication forms: use-once, anonymous, use only by certain
> entity, time-limited (e.g. "expires in 5 minutes").
>
> Could be a SASL mechanism, since SASL has the framework; ultimately
> returning a NO so it can be done multiple times in one IMAP connection.
>
> Must be expressable in an IMAP URL; the URL must carry the authentication
> (possibly also with a client-supplied token).
>
> The idea here is that the MSA is given a message with various IMAP URLs
> inserted.  The MSA resolves the URL and fetches the data from the server
> (or servers -- an advantage of doing it this way).
>
> We need a command for an IMAP client to create these things, e.g. "give me
> a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
> 12383 from my INBOX".

SASL together with a short-lived Kerberos ticket is a somewhat heavy
solution (even heavier if GSSAPI is involved), but possible.

It could be done with a short-lived username/password combination too,
although more difficult to embed useful information you can store in
the ticket (like who created the ticket, useful for logging).

The server could log on the user, using the short-lived authorization
information, and present a restricted view of the mailboxes: only the
appropriate message is available, from one mailbox (INBOX).

SASL definitely has the framework for this, and using it wouldn't
require changes to the IMAP URL either.

My $.2.

Date: Tue, 6 May 2003 14:45:45 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 May 2003, Cyrus Daboo wrote:
> Surely its enough to simply require ACL and require that the MSA have an
> associated user id on the IMAP server and that it be given read/write
> access to each 'real' users' OUTBOX?

No, part of the design is that the MSA does *NOT* have access to anything
that it is not given specific access.

Also, I'm thinking that this may be useful for other things; perhaps I
might want to send someone an email with such a URL (as opposed to the
actual data).

-- Mark --

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

Date: Tue, 06 May 2003 17:44:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Hi Pete,

--On Tuesday, May 6, 2003 10:15 AM -0500 Pete Resnick 
<[email-masked]> wrote:

| Document editors: Please provide to the list the status of your
| documents. Are there open issues that will need to be discussed in Vienna?
|

I have to catch up on the changes to ANNOTATE/ANNOTATEMORE from the last 
meeting - sorry. I will try and get around to that by the end of this week.

| I will be in Vienna either way. Let's figure out now whether we need a
| meeting.

I will not be waltzing over to Vienna :-(

-- 
Cyrus Daboo

Date: Tue, 06 May 2003 17:41:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Vienna
Sender: [email-masked]

Hi Mark,

--On Tuesday, May 6, 2003 2:20 PM -0700 Mark Crispin 
<[email-masked]> wrote:

| The idea here is that the MSA is given a message with various IMAP URLs
| inserted.  The MSA resolves the URL and fetches the data from the server
| (or servers -- an advantage of doing it this way).
|
| We need a command for an IMAP client to create these things, e.g. "give me
| a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
| 12383 from my INBOX".

Surely its enough to simply require ACL and require that the MSA have an 
associated user id on the IMAP server and that it be given read/write 
access to each 'real' users' OUTBOX? Its then a simple matter to write a 
dedicated IMAP client for the MSA that goes and gets messages from each 
OUTBOX on the IMAP server. If you combine this with async notifications for 
STATUS changes (i.e. when a message is added to an OUTBOX) there shouldn't 
be any need to pass a URL to the MSA.

-- 
Cyrus Daboo

Date: Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Vienna
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 May 2003, Pete Resnick wrote:
> Document editors: Please provide to the list the status of your
> documents.

SORT/THREAD: awaiting Chris Newman's i18n document to come out as an I-D
before making Last Call.

> Are there open issues that will need to be discussed in
> Vienna?

Since both UW and Cyrus now implement Alexey's UNSELECT extension, let's
Last Call it.  The I-D is expired.

> Others: Are there items that you think need to be discussed in
> Vienna? Do remember that LEMONADE-related items should be discussed
> over there.

Two things come to mind:

1) Does Chris need help with the i18n I-D?  If so, he should get it.

2) LEMONADE.

LEMONADE clearly identified a need for message submission that does not
require downloading from IMAP server; however, doing submission in IMAP is
a mistake.  I'd rather not argue the reasons why in email; it'll
just waste everybody's time.

Instead, let's come up with an alternative so there is a choice that can
be made.  Right now, there is no choice.

I suggest a command, valid when not logged in, that will fetch a
particular message or portion of message.  Thus, the argument to the
command has to carry authentication of some kind; the key is that this is
*not* the user's authentication but rather some special authentication
that is specific to that message or portion of a message.

Desirable authentication forms: use-once, anonymous, use only by certain
entity, time-limited (e.g. "expires in 5 minutes").

Could be a SASL mechanism, since SASL has the framework; ultimately
returning a NO so it can be done multiple times in one IMAP connection.

Must be expressable in an IMAP URL; the URL must carry the authentication
(possibly also with a client-supplied token).

The idea here is that the MSA is given a message with various IMAP URLs
inserted.  The MSA resolves the URL and fetches the data from the server
(or servers -- an advantage of doing it this way).

We need a command for an IMAP client to create these things, e.g. "give me
a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID
12383 from my INBOX".

> I will be in Vienna either way. Let's figure out now whether we need a
> meeting.

I won't be in Vienna.

-- Mark --

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

Date: Tue, 6 May 2003 10:15:35 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Vienna
Sender: [email-masked]

I've been reminded to start early on figuring out what's going on for 
the next IETF meeting, so let's do that.

Document editors: Please provide to the list the status of your 
documents. Are there open issues that will need to be discussed in 
Vienna?

Others: Are there items that you think need to be discussed in 
Vienna? Do remember that LEMONADE-related items should be discussed 
over there.

I will be in Vienna either way. Let's figure out now whether we need a meeting.
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Michael Fair" <[email-masked]>
To: <[email-masked]>
Cc: "Harrie Hazewinkel" <[email-masked]>
Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips)
Date: Mon, 5 May 2003 18:22:49 -0700
Organization: DaClubhouse
Sender: [email-masked]

I'm looking forward to hearing what others also have to
say about this.

It seems to me that two or three drafts should be used to
replace the current VHOST draft based on this discussion.

While I may have the details wrong, in general, the three
drafts seem to be something along the lines of the following:

1) ECAPABILITY draft (nobody seems to mind ECAPABILITY keyword).
   - This creates ECAPABILITY as a CAPABILITY keyword and
     means that the CAPABILITY command accepts parameters
     for the purposes of informing the server of client
     capabilities and for passing options to capabilities
     the server supports.

2) VHOST draft
   - Redefines VHOST in the context of ECAPABILITY as per
     the details of this discussion.

3) Notification of CAPABILITY as unsolicited responses draft
   - In order to save round trips, allows a server to post
     an unsolicitied CAPABILITY response after the client
     executes any command that changes the CAPABILITY set.
     Currently the identified responses are HELLO, STARTTLS,
     ECAPABILITY, LOGIN, and AUTHENTICATE.  I'd imagine
     that in some servers other commands (like "SELECT")
     might also want/need this ability.

It would also seem that other ideas and drafts might be
recontextualized via ECAPABILITY as well.  For instance,
the LANGUAGE thread that went on a while ago might give
servers the opportunity to store and manipulate folders
in multiple languages and allow the client to define a
preferred language priority list.  Something would have
to be done to allow clients to attach folder names in
different languages to exisitng folders, but that's
outside the scope of the ECAPABILITY draft.

My $0.02,
-- Michael --

----- Original Message ----- 
From: "Harrie Hazewinkel" <[email-masked]>
To: <[email-masked]>
Cc: "Harrie Hazewinkel" <[email-masked]>; "Michael Fair"
<[email-masked]>
Sent: Monday, May 05, 2003 6:54 AM
Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login"
(saving round trips)

> HI all,
>
>
> As being the author of that 'VHOST' command internet-draft
> I was wondering if the group believes it is usefull
> to recycle that draft based on the summary/idea/consensus
> of this discussion??
>
>
> Harrie
>
> On Friday, May 2, 2003, at 05:16 AM, Michael Fair wrote:
>
> >
> >> The really important thing is avoiding round-trips. The
> >> amount of bandwidth
> >> that is taken up by capabilities is really dwarfed by
> >> any messages the client downloads.
> >>
> >> It would be nice, if you're redoing how capabilities
> >> are announced, to do
> >> away with the pointless roundtrips after STARTTLS and
> >> after authentication.
> >
> > I've renamed the subject to reflect the topic.  It's
> > become pretty clear to me that this issue is important
> > but is really separate from adding parameters to the
> > CAPABILITY command.
> >
> > So far the suggestions are to automatically append
> > a CAPABILITY response to any command that changes
> > the current CAPABILITY set.  So far those responses
> > are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if
> > accepted ECAPABILITY.
> >
> > This really sounds more like IMAP4rev2ish but I
> > would suggest including something like:
> >
> > - A Client MUST be prepared to receive an unsolicited
> >   CAPABILITY response after the status response code
> >   of any command.
> >
> > If you wanted to restrict that to "state altering"
> > commands that would probably work too.
> >
> > -- Michael --
>
>

From: "Michael Fair" <[email-masked]>
To: "Lawrence Greenfield" <[email-masked]>, "Timo Sirainen" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips)
Date: Thu, 1 May 2003 20:16:44 -0700
Organization: DaClubhouse
Sender: [email-masked]

> The really important thing is avoiding round-trips. The 
> amount of bandwidth 
> that is taken up by capabilities is really dwarfed by 
> any messages the client downloads.
> 
> It would be nice, if you're redoing how capabilities 
> are announced, to do 
> away with the pointless roundtrips after STARTTLS and 
> after authentication.

I've renamed the subject to reflect the topic.  It's
become pretty clear to me that this issue is important
but is really separate from adding parameters to the
CAPABILITY command.

So far the suggestions are to automatically append
a CAPABILITY response to any command that changes
the current CAPABILITY set.  So far those responses
are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if
accepted ECAPABILITY.

This really sounds more like IMAP4rev2ish but I
would suggest including something like:

- A Client MUST be prepared to receive an unsolicited
  CAPABILITY response after the status response code 
  of any command.

If you wanted to restrict that to "state altering"
commands that would probably work too.

-- Michael --

Date: Thu, 01 May 2003 20:22:27 -0400
From: Lawrence Greenfield <[email-masked]>
To: Timo Sirainen <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: Michael Fair <[email-masked]>, [email-masked]
Subject: Re: Adding a parameter to CAPABILITY
Sender: [email-masked]

--On Friday, May 02, 2003 12:47 AM +0300 Timo Sirainen <[email-masked]> wrote:

>
> On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote:
>> For better compatibility with clients that won't understand ECAPABILITY
>> I  think ECAPABILITY should be a capability value itself. This means
>> that the  greeting string can continue to display the CAPABILITY
>> response code that  some servers now return, but would include
>> ECAPABILITY as one its items:
>>
>> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to
>> you!
>
> I don't really like sending the capability to client automatically. That
> also means that we would receive the capability twice, once at start and
> next after issuing CAPABILITY VHOST (..).

The really important thing is avoiding round-trips. The amount of bandwidth 
that is taken up by capabilities is really dwarfed by any messages the 
client downloads.

It would be nice, if you're redoing how capabilities are announced, to do 
away with the pointless roundtrips after STARTTLS and after authentication.

Larry

From: "Michael Fair" <[email-masked]>
To: "Timo Sirainen" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 16:00:57 -0700
Organization: DaClubhouse
Sender: [email-masked]

> > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to
you!
>
> I don't really like sending the capability to client automatically. That
> also means that we would receive the capability twice, once at start and
> next after issuing CAPABILITY VHOST (..).

You either need to convince people that it's ok for a client
to just try it and then fallback on failure, or the client
needs to get the information twice anyway.  By pre-announcing
we're just short circuiting one of the round trips.

I initially proposed something that utilized the error
codes of existing server to determine if it supported
arguments to CAPABILITY.

An example of that proposal when used against an existing
server would now look like:

* IMAP Server - Hello there!
C: 1 CAPABILITY VHOST (fqdn.example.com) ...
S: 1 BAD Unexpected extra arguments to Capability
C: 2 CAPABILITY
* CAPABILITY IMAP4rev1 ...
S: 2 OK Completed

I expected that over time servers would come to deal
with the added arguments (first just by swallowing them
and not returning BAD, but still responding to CAPABILITY)
and so the only "wasted bandwidth" was during the initial
introduction of the parameter, and only when new clients
were used against old servers.  Existing servers are
prepared for such "malformed" requests so I was just
taking advantage of "corerct behavior".

I, like yourself, was trying to minimize the number of
times a client had to parse a CAPABILITY response.
But people didn't like that the client didn't at least
have a method for having foreknowledge, so it forced
a round trip.

That example would now look like:

* IMAP Server - Hello there!
C: 1 CAPABILITY
S: * CAPABILITY  IMAP4rev1 ECAPABILITY ...
S: 1 OK Completed
C: 2 CAPABILITY VHOST (fqdn.example.com) ...
S: * CAPABILITY  IMAP4rev1 ECAPABILITY VHOST (fqdn.example.com) ...
S: 2 OK Completed

Which still makes the client make two round trips, but
now it has to actually pay attention to the result of
the first one just to find out if it can issue the second.
Of course, there's nothing stopping a client from doing
it the way I first proposed.  I have no reason to believe
the first proposal is "wrong" in anyway.

But let's stick to the new method.
So the client issues a CAPABILITY line to find out if it
can issue a parameterized CAPABILITY line.  Well that's
two round trips and two CAPABILITY parses.  That kinda
sucks, why don't we "preannounce" the first CAPABILITY
command that we know the client is going to have to
issue anyway and save the client at least one round trip?

If we don't pre-announce the capabilities we make the client
fetch for it.

Now these same semantics are not only related to ECAPABILITY
also AUTHENTICATE and probably others.  So the thought is
that if we are going to bother with preannouncing something
we might as well preannounce the whole capability response.
This will save all clients at least one round trip regardless
of what they are going to do.

Of course we could/should break this out into two
extensions - One is ECAPABILITY (for lack of a formal term)
and the other is "CAPABILITY ON HELLO".

If we did that, would you be satisfied that ECAPABILITY
on its own and as its own CAPABILITY term is fine, and
then talk about the merits of "CAPABILITY ON HELLO"
in a different thread?

-- Michael --

Subject: Re: Adding a parameter to CAPABILITY
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Michael Fair <[email-masked]>, [email-masked]
Organization: 
Date: 02 May 2003 00:47:22 +0300
Sender: [email-masked]

On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote:
> For better compatibility with clients that won't understand ECAPABILITY I 
> think ECAPABILITY should be a capability value itself. This means that the 
> greeting string can continue to display the CAPABILITY response code that 
> some servers now return, but would include ECAPABILITY as one its items:
> 
> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

I don't really like sending the capability to client automatically. That
also means that we would receive the capability twice, once at start and
next after issuing CAPABILITY VHOST (..).

From: "Michael Fair" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, <[email-masked]>
Subject: Re: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 14:11:13 -0700
Organization: DaClubhouse
Sender: [email-masked]

> Hi Michael,
>
> --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair
> <[email-masked]> wrote:
>
> | Any and all feedback is welcome and encouraged.
> | Especially in finding the string to put in the
> | Hello response.
>
> For better compatibility with clients that won't
> understand ECAPABILITY I think ECAPABILITY should
> be a capability value itself. This means that the
> greeting string can continue to display the
> CAPABILITY response code that some servers now
> return, but would include ECAPABILITY as one its items:
>
> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

I've got no problem with that at all. :)
I'll keep an ear open for calling it something
other than ECAPABILITY, "CLIENTCAPABILITY" has also
been suggested, I missed mentioning it earlier.

Anyone else have any other suggestions or should
we move on to actually drawing up a draft?

If we should move on to drawing up a draft, are
there any other currently proposed extensions aside
from VHOST that this new draft should supercede?

I would love to hear some feedback from more
server implementors and client writers that are
on the list as to their opinion on how this
should proceed.  What changes, if any, would help
make their lives easier and thus more likely to
add this command into their code.

-- Michael --

Date: Thu, 01 May 2003 16:35:24 -0400
From: Cyrus Daboo <[email-masked]>
To: Michael Fair <[email-masked]>, [email-masked]
Subject: Re: Adding a parameter to CAPABILITY
Sender: [email-masked]

Hi Michael,

--On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair 
<[email-masked]> wrote:

| Any and all feedback is welcome and encouraged.
| Especially in finding the string to put in the
| Hello response.

For better compatibility with clients that won't understand ECAPABILITY I 
think ECAPABILITY should be a capability value itself. This means that the 
greeting string can continue to display the CAPABILITY response code that 
some servers now return, but would include ECAPABILITY as one its items:

* OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you!

-- 
Cyrus Daboo

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Adding a parameter to CAPABILITY
Date: Thu, 1 May 2003 13:05:47 -0700
Lines: 89
Sender: [email-masked]

After much discussion about the VHOST feature
for virtualizing domains and being able to
reliably host multiple domains on a single IP.

The general consensus is that being able to reliably
host multiple domains on a single IP is useful,
using a parameter to STARTTLS, while preferred
and already supported with a STARTTLS draft
extension, is unreliable, and that any of the other
recommended solutions essentially equates adding a
parameter to CAPABILITY, finally, that if we are
going to bother adding a parameter to CAPABILITY
we might as well make it so that future
modifications of a similar type don't need another
modification to the protocol and thus a client
should be able to submit its own capability options
to the server when it makes a capability request.

This feature in general is being referred to as
a "Client CAPABILITY" line.  It's purpose is to
inform the server of any capabilities the client
has that the server may need to be informed of
(no current need has been identified for this though
there are potential ideas for its use) and to pass
parameters to the server for any capabilities
the server offers that may be modified (this is
the feature that VHOST would use).

As such, the current proposal on the table
goes along the lines of:

1) A specific string is added to the HELLO response
   to notify the client that a client capability
   parameter is supported.  The only string suggested
   as of yet is "[ECAPABILITY]" following with ESMTP.
   Other suggestions are requested.

2) A client MAY provide a CAPABILITY parameter if it
   saw the appropriate string in the HELLO response.
   The client capability should match syntax with the
   existing CAPABILITY response to prevent servers
   from having to invent new parsers.

3) The CAPABILITY response from the server MUST
   acknowledge each parameter response it understands
   to inform the client of the accepted parameters and
   their status.  Absence of a parameter in the servers
   CAPABILITY response means the server does not support
   or does not understand that particular CAPABILITY.
   Syntax errors on parameters that the server does
   understand SHOULD respond with "BAD" and give the
   appropriate reason for failure.

4) While a client capability parameter may be supported
   the rules which govern the individual options are
   defined on a per instance basis.
   For instance, with VHOST, once a client has entered
   into a TLS session or the AUTHENTICATED state, if
   the client should issue another CAPABILITY line the
   VHOST parameter SHOULD NOT be changed, and if the
   client does try and change it, the server SHOULD
   respond with "No" indicating the VHOST parameter
   has been changed and is invalid (an exception might
   be made for server administrator users).  It is
   considered a security risk to allow clients to
   jump between domains once they are in a TLS session
   or the AUTHENTICATED state.

So an example conversation might be the following (note
the server does not support LANGUAGE and so leaves it out
of its response to CAPABILITY):

S: * OK [ECAPABILITY] IMAP server ready.
C: 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB)
S: 1 OK [CAPABILITY IMAP4rev1 VHOST (fqdn.example.com) RLIST ...]
C: 2 STARTTLS
S: 2 OK
...etc...

Any and all feedback is welcome and encouraged.
Especially in finding the string to put in the
Hello response.

-- Michael --