Subject: Re: I-D ACTION:draft-daboo-imap-view-01.txt (fwd)
From: Pete Resnick <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Thu, 28 Oct 1999 13:48:16 -0500
List-Id: <ietf-imapext.imc.org>

On 10/28/99 at 2:37 PM -0400, Cyrus Daboo wrote:

>PS This got delayed because I originally submitted it under 
>draft-ietf-imapext but the document editors claimed there was no 
>such WG. I think we need to get this straightened out!

Yes, this was my fault. I got the charter in too late for Keith and 
Patrik to bring it to the IESG for approval before the meeting in DC. 
We will be a WG soon, I promise.

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

Date: Thu, 28 Oct 1999 14:37:41 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imap-view-01.txt (fwd)
Sender: [email-masked]

--==========00575812==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
An updated VIEW extension draft is available at the IETF drafts repository
as indicated below. This is the second version of the VIEW extension draft
and incorporates changes discussed on the list and at the last meeting in
Oslo. I've attached another text part to this message listing the changes
made between -00 and -01.

Note that the issue of static vs semi-dynamic vs fully dynamic updates is
still undecided (at least that's the impression I got after the last round
of messages on that topic) so this was not changed in the draft, which
still describes a fully dynamic mechanism. I suggest this be one of the
main items on the agenda for the WG meeting in a couple of weeks.

PS This got delayed because I originally submitted it under
draft-ietf-imapext but the document editors claimed there was no such WG. I
think we need to get this straightened out!

---------- Forwarded Message ----------
Date: Thursday, October 28, 1999 7:08 AM -0400
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imap-view-01.txt

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

	 Title		: IMAP VIEW Extension
	 Author(s)	: C. Daboo, M. Pustilnik, M. Crispin
	 Filename	: draft-daboo-imap-view-01.txt
	 Pages		: 14
	 Date		: 27-Oct-99
	 
The VIEW extension to the Internet Message Access Protocol [IMAP4]
permits a subset of messages in the mailbox to be processed
separately from the entire set of messages in the mailbox.  This
allows a client to restrict its view to only the messages appearing
in this set.  The subset of messages also need not be returned in
order of their sequence numbers, allowing clients to access messages
in a particular sort order.

---------- End Forwarded Message ----------

--
Cyrus
--==========00575812==========
Content-Type: text/plain; charset=us-ascii; name="view_changes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="view_changes.txt"; size=3068

View Draft Changes

General
- Added option to allow VIEW SET command arguments during a SELECT or
EXAMINE command as agreed in Olso.
- Changed text to describe VIEW as a single command and a single response,
with different variants.

3 Introduction
- (c) removed VIEW item in FETCH command as there is never any need to
explicitly request it as its always returned when view is in effect.

4.1 VIEW SET Command
- Added clarification on valid sub-commands: only SEARCH for now but may
allow SORT and THREAD in future.
- (c) changed to apply to ALL fetch responses not just unsolicited.
- (c) removed reference to VIEW item in FETCH command.
- Added (h) to clarify resetting a view using another VIEW SET.
- Added (i) to clarify cancellation of a view if SELECT, EXAMINE or CLOSE
occur.

4.3 (was 4.2) VIEW Command
- Added statement that VIEW command is only valid when VIEW SET in effect.

5.1.1
- Removed previous restriction on not sending VIEW response when no command
is in effect. This contradicts the requirement that VIEW responses for new
messages must be sent after an EXISTS.

5.1.2
- Clarified restrictions on when VIEW response for moving messages can be
sent.
- Corrected 'non-zero' to 0 in a couple of places.
- Added section on both <old> and <new> being non-zero.
- Corrected examples which had <new> and <old> values reversed.

6
- Revised to be compliant with RFC2234.
- Modified syntax to reflect VIEW as a single command and response.
- Added syntax for modified SELECT and EXAMINE commands.
- Added msg-att-dynamic for VIEW message data item in FETCH.
- Alphabetic sort of formal syntax terms.

--==========00575812==========--

Date: Wed, 13 Oct 1999 14:32:12 -0600
From: Alexey Melnikov <[email-masked]>
To: Mike Gahrns <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: draft-gahrns-imap-language-01
Sender: [email-masked]

Alexey Melnikov wrote:

> > >    4). Primary language: Accordingly to Alvestrand RFC language tag is not
> always
> > > hierarchical. This means that you can't always assume that x-y-z is
> sublanguage of x-y.
> > > This means that server should have some additional knowledge about languages
> it
> > > supports.
> > *** Can you suggest some text to address this?

Ok, let me do the first try (BTW, I am referencing
draft-alvestrand-lang-tags-v2-00.txt, not RFC 1766):

>4. LANGUAGE Command
>
>   Arguments: Zero or one language tag as defined by [RFC-1766].

Add the following text: "Language tags MUL (Multiple languages) and Und
(Undetermined) MUST NOT be used."
Same text should be added to ABNF section.

After the text

>             If a sublanguage was asked for and not available but the
>             primary language is available, the server should switch to
>             the primary language and include a LANGUAGE response
>             containing the identifier of the primary language it
>             switched to.

add the following:

It is also recommended that server recognizes languages that have multiple
different tags (like "ru" and "rus").

Note 1. Client MUST NOT use MUL (Multiple languages) and Und (Undetermined)
language tags and server MUST return BAD to the LANGUAGE command with such
parameter.

Note 2. [LANG-TAG] (draft-alvestrand-lang-tags-v2-00.txt) warns that there is no
guaranteed relationship between languages whose tags start out with the same
series of subtags. However it is believed that for the purpose of this document it
is safe to treat all languages, whose tags starts with primary language described
in ISO 639-1 and ISO 639-2 (i.e. all 2 or 3 letters primary languages) as
hierarchical. For all languages with other primary tags fallback rule MUST not be
used. In particular, language tags starting with 'i-' and 'x-' SHOULD NOT be
treated as hierarchical.
---------------
Alexey Melnikov
Software Developer    phone: (780) 424 4922 x 357
MessagingDirect Ltd.  fax  : (780) 424 4925

mailto:[email-masked]
http://www.MessagingDirect.com

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Cc: "Pristin, Dmitry" <[email-masked]>, "Neystadt, John" <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Sat, 9 Oct 1999 16:53:53 +0200 
Sender: [email-masked]

> From: Larry Osterman (Platinum) [mailto:[email-masked]]
> Sent: Friday, October 08, 1999 12:02 AM
> To: Tony Hansen; [email-masked]
> Subject: RE: draft-karppinen-imap-conman-00.txt
> 
> 
> Comments within, but warning - they are a bit long, but I 
> think relevant. 

The comments are (IMHO) very relevant. I was even moved to write a response,
which I initially had no inclination of doing.

> I guess I have a REALLY hard time believing that the cost of 
> creating/destroying a socket is significant relative to the 
> cost of actually performaing the relative IMAP operations.  

Exactly. Which leads to the conclusion: HTTP thingies that are IMAP clients
will suffer much greatly from the initial IMAP commands than from the socket
connection. On each HTTP transaction the CGI script (or ASP, or whatever
there is) will have to issue the following set of commands (or a similar
one):

LOGIN/AUTHENTICATE (can be pretty slow, if the authentication performed
against a busy, remote authentication server)
SELECT something (can be pretty slow when the mailbox is large and it's a
remote one, say, another IMAP client)
FETCH 1:* (UID FLAGS)

I'm pretty sure the penalty of issuing these commands is greater than that
of creating a new connection. Especially if you work in a thread-per-session
or constant-number-of-threads modes. We've also encountered this problem
while trying to make our IMAP server work as an HTTP back end. Our solution
is different (and it has already been implemented). It's goal is to solve
the problem of initial synchronization with the server.

The following two commands are introduced: X-CNS-LOGOUT, X-CNS-LOGIN. 

The CGI script, once finished fetching the relevant data, issues the
X-CNS-LOGOUT command. The response includes a session ID, which is unique
per something (say, lifetime of the server). The server then disconnects the
client, while keeping all of the session's state. On the next HTTP
transaction, the CGI script connects to the IMAP server and issues the
X-CNS-LOGIN command, passing on the session ID as a parameter. The session's
state is then restored. Once the HTTP client issues a logout (or on other
circumstances, when the session is considered over), the IMAP client issues
the usual LOGOUT command and the session's state is then scraped.

Basically, what it does is caches IMAP session instead of forcing the client
to do that. If the server is implemented in an efficient way, it may be
quite easy to implement.

That's it, in a nutshell. We've implemented this thing as a special proxy,
being reluctant for the moment to change the code of our IMAP server, but
the code can easily be incorporated into the server itself. There might be a
problem with load-balancing systems, that, perhaps, can be solved using IMAP
login referrals. Also there might be a security risk in using session IDs,
but this can be solved with ACLs. 

We never intended to publish this extension (as you might have noticed by
the 'X' in the command names), due to, mainly, lack of interest in the
community (as we saw it) and also, due to history of failed attempts at IMAP
standardization on our behalf. However, there seems to be certain interest
in the protocol driven solution to the problem of performance of IMAP
clients that are 'connectionless', and here we are. So, if someone else
finds this useful, we are willing to push it through.

--
Dmitry Rubinstein 

Date: Fri, 8 Oct 1999 15:12:17 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

A few points about all this.

LDAP, which otherwise uses SASL in a very similar manner to IMAP (since it
was following the example set by IMAP), has an Unbind operation (see RFC
2251 section 4.3) which is more or less identical to the proposed IMAP
USERLOGOUT command.  I believe this was part of the DAP command set that
was just carried over into LDAP.  But certainly as the LDAP authentication
details were being worked on (in draft-ietf-ldapext-ldapv3-tls-05.txt and
draft-ietf-ldapext-authmeth-04.txt) implementors made it known that being
able to de- and re-authenticate the connection was important to them, I
think for more or less the same reasons as the pro-USERLOGOUT folks give
here.  I have no idea how much this is used in practice.

The connection-reuse strategy proposed by the USERLOGOUT proponents is
similar to the "connection pooling" technique that is universally used, in
my experience, in 3-tier database-oriented apps these days, especially
those with a web front end (ie, all new ones).  A set of database
connections is created by the app-server at system startup time, and
connections are grabbed and released by app-server threads as needed.  
The authentication story is somewhat different than it would be with IMAP,
though, since generally the app-server authenticates to the database
service as itself at connection start time, and app-level authentication
identity is one of the parameters in each database op; so there isn't a
USERLOGOUT equivalent in this case.

So, there's certainly adequate precedent in other areas for the approach
proposed in this draft; I think the question at hand is whether this is
worth adding to a protocol that doesn't have it already.  I think what the
anti-USERLOGOUT implementors are saying is that if you came to them and
said that the performance cost of simply making a TCP connection is a
substantial fraction of the total cost of starting an authenticated
session, as is claimed in the draft:

   Initial profiling suggests
   that persistent IMAP4 connections can lead to a performance increase
   of an order of magnitude when compared to separate IMAP4 connections
   per mailbox action.

that they would scurry off and make it not be so, and that this is doable,
and should be done, without requiring any protocol changes.

So, this is a performance hack.  The only way to decide whether it's
justified is with numbers.  I think it's up to the proponents to post real
observed numbers; and then for the anti- implementors to refute them or do
the implementation mods to prove that the remediation can be done without
protocol mods.

As someone mentioned, adding this capability in the context of TLS makes
things even trickier.  Let me philosophize on this point.  TLS basically
has its own set of security states that can change more or less
independently of the application protocol (SASL) states; the job of the
profile is to tie these together appropriately.  We dealt with some of
this in the ldapv3-tls spec, see specifically section 7.2 which says that
ending a TLS connection undoes any authentication state in the LDAP
connection; but that the LDAP connection itself can continue after TLS is
stopped.  (RFC 2595 doesn't address this issue, which is an omission.)  
See

 http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.html

for an excellent state diagram of this behavior.  This is necessary to
specify the relevant behavior if you want TLS to be STOPpable as well as
STARTable.

Another look at RFC 2246 on TLS shows that at any time during a TLS
connection the handshake protocol can happen again, which can result in a
new set of security conditions and in particular a new client cert.  I
don't think any of the current app profiles for TLS take this into
account, even to the extent of saying "prohibited".  But if you wanted 
USERLOGOUT to work in the TLS+client_cert case (and surely this is an
increasingly important case) you'd probably say that *if* TLS is in use
and the client was authenticated via a cert, *then* USERLOGOUT would also
cause the server to issue a handshake protocol hello to renegotiate the
TLS authentication; or you might say that the TLS connection had to close,
but that's going to knock holes in the performance argument.

I find it hard to believe that performance gains (that aren't achievable
any other way) are enough to motivate USERLOGOUT as a standard facility,
given the non-trivial complexity of fully specifying (not to mention
implementing) the behavior it implies.

 - RL "Bob"

Date: Fri, 08 Oct 1999 09:40:58 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> Lyndon Nerenberg wrote:
> 
> > There's another problem with this. It's not going to work in
> > the presence of SASL session integrity or protection. There's
> > no provision in 2060 for turning either of these off once they've
> > been established,
> 
> Exactly. Currently IMAP SASL profile doesn't allow to clear SASL state.
> RFC 2222 (SASL), says:
> 
>     5.3.  Multiple authentications
> 
>        Unless otherwise stated by the protocol's profile, only one
>        successful SASL negotiation may occur in a protocol session.
>        In this case, once an authentication protocol exchange has
>        successfully completed, further attempts to initiate an
>        authentication protocol exchange fail.

Note again the statement above "Unless otherwise stated by the
protocol's profile". This proposed extension definitely affects a lot of
things. One of those areas it affects is the SASL profile for IMAP.

But that's okay; it just needs to be acknowledged within the proposed
extension that it extends the SASL profile for IMAP as well as the IMAP
protocol.

Lyndon Nerenberg wrote:

>    Tony> Lawrence's reply answers this objection sufficiently:
>    >> The SASL specification says that a layer ends when another
>    >> layer is turned on, ....
>
> No it doesn't. SASL may provide a mechanism, but 2060 doesn't. 2060
> would have to be changed to explicitly call out the behaviour during
> the state change. I.e., when exactly is integrety/protection turned
> off?
>
> Allowing an IMAP session to switch out of authenticated state
> (in any manner) seems to me to be a fundamental change to the
> semantics of the protocol. It's not extending the protocol, it's
> changing it. I don't think the IETF standards process allows us to
> do this.

Within the IMAP protocol, there already exists a transition out of
authenticated state (LOGOUT or drop connection). The proposed change to
the IMAP state machine is one additional transition from authenticated
or selected state to non-authenticated state. There are no new states.
IMNSHO, this is NOT a fundamental change.

Here's a revised state diagram showing the additional transition:

            +-------------------------------------------+
            |  initial connection and server greeting   |
            +-------------------------------------------+
                       || (1)           || (2)        || (3)
                       VV               ||            ||
            +-----------------------+   ||            ||
            |   non-authenticated   |   ||            ||
            +-----------------------+   ||            ||
             || (7) ^^ (8)    || (4)    ||            ||
             ||     ||        VV        VV            ||
             ||     ||   +----------------+           ||
             ||     ++<==| authenticated  |<=++       ||
             ||     ||   +----------------+  ||       ||
             ||     ||     || (7)   || (5)   || (6)   ||
             ||     ||     ||       VV       ||       ||
             ||     ||     ||    +--------+  ||       ||
             ||     ++=====||====|selected|==++       ||
             ||            ||    +--------+           ||
             ||            ||       || (7)            ||
             VV            VV       VV                VV
            +-------------------------------------------+
            |       logout and close connection         |
            +-------------------------------------------+

         (8) successful USERLOGOUT command

>    Tony> No, it's not something that most clients will utilize, nor
>    Tony> is it something that all servers need implement. But in
>    Tony> some contexts, such as the web-based email service mentioned
>    Tony> by Marko,
>
> The web server is just another IMAP client. It can, and should, cache
> IMAP connections just like any other IMAP client would.

Exactly. In one sense, web-based email servers are fundamentally
different from other IMAP clients. Because of the connectionless nature
of HTTP, they are servicing multiple users while trying to maintain the
fiction of a single maintained connection for each user. There are
several ways of doing this. Some of them cache the IMAP connections,
others don't. The ones that don't cache the connection aren't going to
be able to use this extension. But the ones that do can benefit, because
this extension now allows such caching to continue past the servicing of
a single user (serial mode), as well as allowing a single cached
connection to be used to service multiple users (bounce mode), neither
of which was not formerly possible.

	Tony Hansen
	[email-masked]

Date: Fri, 08 Oct 1999 08:27:01 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

"Larry Osterman (Platinum)" wrote:

> > No, there's no such assumption in this extension. The two concepts
> are
> > totally orthogonal. Each IMAP connection is a totally separate
> entity,
> > in and of itself, whether it maps into a thread on the server, or a
> > process, or whatever. Being able to manage those connections in a
> way
> > that lets the client reuse them is useful, for SOME CLIENTS.
> 
> Actually there is such an assumption - the stated purpose of this
> extension was to increase scalability in a n-tier environment.  See
> the abstract of the draft.  It clearly states that the design of the
> extension is driven by the high cost of connections:
> 
>    In such scenario, a component of a n-tier system may act as an
>    IMAP4 client on behalf of multiple end-users.  Present examples
>    of this include many WWW-based email services.  Initial profiling
>    suggests that persistent IMAP4 connections can lead to a
>    performance increase of an order of magnitude when compared to
>    separate IMAP4 connections per mailbox action.

If you add back the statement before this (deleted by Larry)

> The problem is that the perceived need for this facility in IMAP is
> based upon two assumptions:
>  1) The IMAP protocol requires one process per connection.

you'll see that Larry and I are arguing about two totally different
matters. I agree completely that the reason for the extension is "driven
by the high cost of connections". However, this has nothing to do,
necessarily, with processes, but is entirely about connections. As has
been pointed out, there are many architectures for IMAP servers and the
presumed assumption (1 process == 1 connection) is false. So holding
this assumption up as something to bash is a red herring.

> [N.B. ... lots of stuff leading up to this ...]
> Q:      But what if the client connection is NOT as long as the server
> connection?
> A:      Ahhh...  That must be it.  The server in question must in fact
> be an HTTP gateway backed by IMAP.  Since HTTP is a connectionless
> protocol, the server must be reestablishing the IMAP connection on
> EVERY incoming HTTP request.  In such an environment, the connection
> establishment time CAN start to overwhelm the operational cost, since
> you will be executing at most one authenticated IMAP verb for each
> HTTP request.
> 
> Why did I just waste all that time getting to this place?  To point
> out that there is only ONE case where this extension is of real
> benefit (which is confirmed by Tony and Marko's mail).  And that case
> is where you have an HTTP->IMAP proxy server that is written on HTTP
> 1.0.

Marko stated his reasons for this up front. Your list of logical steps
left off the possibilities of some alternatives at a few steps, but
definitely showed why this extension is needed for at least one
particular type of architecture.

> If it was written using HTTP 1.1, it would be possible to use
> fact that HTTP 1.1 is (sort-of) connection oriented to avoid
> continually reestablishing the connection with the IMAP server.
>
> My claim is that even if you use HTTP 1.0, you can put enough context
> in your URLs to allow you to use only one connection per HTTP CLIENT
> when talking to the server (as opposed to one connection per HTTP
> VERB).  You already have to cache the users  authorization credentials
> on the server (or you force the user to reauthenticate on every
> click), you can use this cache to hold your cached connection state.

This is an alternative architecture that leads to some other trade offs.
Yes, it may be viable in some places, but isn't always. 
Also, some scenarios appear even in architectures that do maintain
connections per CLIENT instead of per VERB, forcing them to start
reusing those connections for multiple client sessions.

> > No, it's not something that most clients will utilize, nor is it
> > something that all servers need implement. But in some
> > contexts, such as
> > the web-based email service mentioned by Marko,
> >
> >     o it is extremely useful in those contexts
> >
> >     o it's already been implemented differently in at least two
> > implementations
> >
> >     o it's worth standardizing on a single syntax
> >
> >     o (from the draft) "persistent IMAP4 connections can lead to a
> > performance increase of an order of magnitude when compared
> > to separate
> > IMAP4 connections per mailbox action"
> 
> If this is the case, then this should be submitted an experimental or
> informational extension and NOT standards track extension.  

Excellent idea. That would potentially avoid lots of hassle.

> You're going to have a REALLY hard time finding interoperable
> implementations if it's only implemented in your propriatary code
> bases.

That's just it; we'd love for it NOT be implemented in a proprietary
way. That way we could mix and match servers that implement it and have
a way of saying "if your server supported this feature, it would have a
higher chance of being in the running for us using it".

And I don't think there'd be a problem finding interoperable
implementations. We've already got two server developers that would like
to have a go at it.

	Tony Hansen
	[email-masked]

Date: Fri, 08 Oct 1999 09:00:48 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------B330542C269D9A376C4A5501
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> Mark Crispin wrote:
> >
> > I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
> > already defines an excellent multiplexing facility: TCP.  You are going to
> > encounter enormous opposition to duplicating TCP's work, especially in the
> > name of working around poorly-designed operating systems.
>
> Red herring. It's not reinventing multiplexing. It's introducing
> serialization at the application level within the context of an existing
> TCP connection. No duplication of TCP's work is happening.
>
> This is totally comparable to issuing another MAIL FROM to an SMTP
> connection after the first message's DATA block is sent. This feature is
> used by SMTP systems around the world today for the same reason: to
> avoid establishing a new socket between messages.
>

Precisely.

What most of the complainants seem to have missed is that setting up a secure
TCP link from (say) a web server to an IMAP server inside a firewall can be very
expensive.  Authentication negotiations and whatnot can easily dwarf the time
taken to login, check new mail and logout.  One should also bear in mind that
setting up the per-connection context for an IMAP connection varies from
ridiculously expensive to the relatively cheap.  (At either end of the spectrum,
it is possible for this IMAP set-up/tear-down to dominate a busy system.)

The arguments about SASL also also a red herring -- SASL is about authentication,
having established the users authenticity, the connection can be dropped back to
its pre-authenticated state with USERLOGOUT.  The security risks of doing so are
no greater than those imposed by dropping the connection and re-connecting (apart
from the time involved).

Of course, if one were to use TLS for authentication purposes, then one wouldn't
be able to use USERLOGOUT, but that is a completely different issue.
Non-authenticating TLS (and SSL which doesn't do authentication) is a different
matter of course.

jch

--------------B330542C269D9A376C4A5501
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------B330542C269D9A376C4A5501--

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: "Tony Hansen" <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Thu, 7 Oct 1999 15:02:10 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_30267_01BF10D4.F0B750C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments within, but warning - they are a bit long, but I think
relevant.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

>=20
> No, there's no such assumption in this extension. The two concepts are
> totally orthogonal. Each IMAP connection is a totally separate entity,
> in and of itself, whether it maps into a thread on the server, or a
> process, or whatever. Being able to manage those connections in a way
> that lets the client reuse them is useful, for SOME CLIENTS.

Actually there is such an assumption - the stated purpose of this
extension was to increase scalability in a n-tier environment.  See the
abstract of the draft.  It clearly states that the design of the
extension is driven by the high cost of connections:

   In such scenario, a component of a n-tier system may act as an IMAP4
   client on behalf of multiple end-users.  Present examples of this
   include many WWW-based email services.  Initial profiling suggests
   that persistent IMAP4 connections can lead to a performance increase
   of an order of magnitude when compared to separate IMAP4 connections
   per mailbox action.

> > 2) The costs of creating and destroying a process per=20
> connection are high.
> >
> > Assumption (2) also has clay feet; process=20
> creation/destruction is slow
> > because OS vendors have never felt the need to fix it.
>=20
> Bad assumption in the counter argument, as this may not have=20
> anything to
> do with creating and destroying a process per connection. If=20
> the server
> were implemented using threads, or some other paradigm that avoids
> process creation and destruction per connection, the fact remains that
> the very act of creating a socket connection is expensive on most
> current OS's. Maybe someday these limitations will also disappear, but
> that doesn't mean that the problem doesn't exist today and isn't worth
> providing for.

I guess I have a REALLY hard time believing that the cost of
creating/destroying a socket is significant relative to the cost of
actually performaing the relative IMAP operations.  And if it IS, I
further claim that the platform itself is broken and should be
considered as an inappropriate platform for a high performance server.
See my Socratic dialogue below.

> > (3) The servers that could benefit from this proposal would=20
> implement it.
>=20
> Sorry to disappoint you, Mark. You need to look at this from total
> system perspective. It's not the servers that would benefit from the
> proposal, but instead embedded systems acting as IMAP clients. These
> clients are using the IMAP servers in certain fashions of which you
> haven't yet considered all the ramifications. Marko's example of a web
> based email service is such an embedded system. I work with developers
> of similar systems as well, and this type of extension has=20
> already being
> implemented for them. The "combination of the client and server both
> supporting and using this extension" definitely can benefit from the
> extension, and have already done so.
>=20

I'm going to take issue with even this statement.  Lets work the logic
out step by step.

Q:	When does this proposal benefit a platform?
A:	When the cost of establishing/receiving a connection is a
significant percentage of the overall cost of the operation.  There are
no other cases where this is interesting.

Q:	When would the cost of RECEIVING a connection be a significant
percentage of the cost (ie. on the Server)?
A:	If the design of the server software is one-process-per-user, or
if the OS overhead of socket creation is too high.

Q:	Are there any solutions other than this extension that resolve
this?
A:	Yes.  As mentioned above, the IMAP server can be rewritten to
use a model other than one-process-per-user.

So if this extension is still needed, it is likely to be some
requirement of the CLIENT, not the server that is driving it (since the
server side can be fixed).

Q:	When would the cost of ESTABLISHING a connection be a
significant percentage of the cost (ie. on the Client)?
A:	When the client OS software makes it expensive - it might have
to dial a modem, etc.  But that begs the next question:

Q:	Would this extension help this case?
A:	No - what CLIENTS would be simultaneously supporting multiple
users?  Certainly not handheld devices or PCs.  The only case where a
CLIENT simultaneously supports multiple users is in the case of a proxy
client of one form or another.

So this extension is really targeted at improving the efficiency of
proxy servers (yes, I know this was a long road to go through to get
back to what Marko mentioned in his initial mail, but please bear with
me, I'm actually going somewhere with this).

Q:	So what is it about a proxy server that makes this extension
necessary?
A:	Nothing - proxy servers can establish a connection that lasts as
long as the client connection, so this isn't a big deal.

Q:	But what if the client connection is NOT as long as the server
connection?
A:	Ahhh...  That must be it.  The server in question must in fact
be an HTTP gateway backed by IMAP.  Since HTTP is a connectionless
protocol, the server must be reestablishing the IMAP connection on EVERY
incoming HTTP request.  In such an environment, the connection
establishment time CAN start to overwhelm the operational cost, since
you will be executing at most one authenticated IMAP verb for each HTTP
request.

Why did I just waste all that time getting to this place?  To point out
that there is only ONE case where this extension is of real benefit
(which is confirmed by Tony and Marko's mail).  And that case is where
you have an HTTP->IMAP proxy server that is written on HTTP 1.0.  If it
was written using HTTP 1.1, it would be possible to use fact that HTTP
1.1 is (sort-of) connection oriented to avoid continually reestablishing
the connection with the IMAP server.

My claim is that even if you use HTTP 1.0, you can put enough context in
your URLs to allow you to use only one connection per HTTP CLIENT when
talking to the server (as opposed to one connection per HTTP VERB).  You
already have to cache the users  authorization credentials on the server
(or you force the user to reauthenticate on every click), you can use
this cache to hold your cached connection state.

> No, it's not something that most clients will utilize, nor is it
> something that all servers need implement. But in some=20
> contexts, such as
> the web-based email service mentioned by Marko,
>=20
>     o	it is extremely useful in those contexts
>=20
>     o	it's already been implemented differently in at least two
> implementations
>=20
>     o	it's worth standardizing on a single syntax
>=20
>     o	(from the draft) "persistent IMAP4 connections can lead to a
> performance increase of an order of magnitude when compared=20
> to separate
> IMAP4 connections per mailbox action"

If this is the case, then this should be submitted an experimental or
informational extension and NOT standards track extension.  You're going
to have a REALLY hard time finding interoperable implementations if it's
only implemented in your propriatary code bases.

------=_NextPart_000_30267_01BF10D4.F0B750C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Comments within, but warning - they are a bit long, =
but I think relevant.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; No, there's no such assumption in this =
extension. The two concepts are</FONT>

<BR><FONT SIZE=3D2>&gt; totally orthogonal. Each IMAP connection is a =
totally separate entity,</FONT>

<BR><FONT SIZE=3D2>&gt; in and of itself, whether it maps into a thread =
on the server, or a</FONT>

<BR><FONT SIZE=3D2>&gt; process, or whatever. Being able to manage those =
connections in a way</FONT>

<BR><FONT SIZE=3D2>&gt; that lets the client reuse them is useful, for =
SOME CLIENTS.</FONT>
</P>

<P><FONT SIZE=3D2>Actually there is such an assumption - the stated =
purpose of this extension was to increase scalability in a n-tier =
environment.&nbsp; See the abstract of the draft.&nbsp; It clearly =
states that the design of the extension is driven by the high cost of =
connections:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; In such scenario, a component of a n-tier =
system may act as an IMAP4</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; client on behalf of multiple =
end-users.&nbsp; Present examples of this</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; include many WWW-based email =
services.&nbsp; Initial profiling suggests</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; that persistent IMAP4 connections can =
lead to a performance increase</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; of an order of magnitude when compared =
to separate IMAP4 connections</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; per mailbox action.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; 2) The costs of creating and destroying a =
process per </FONT>

<BR><FONT SIZE=3D2>&gt; connection are high.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Assumption (2) also has clay feet; process =
</FONT>

<BR><FONT SIZE=3D2>&gt; creation/destruction is slow</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; because OS vendors have never felt the need =
to fix it.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Bad assumption in the counter argument, as this =
may not have </FONT>

<BR><FONT SIZE=3D2>&gt; anything to</FONT>

<BR><FONT SIZE=3D2>&gt; do with creating and destroying a process per =
connection. If </FONT>

<BR><FONT SIZE=3D2>&gt; the server</FONT>

<BR><FONT SIZE=3D2>&gt; were implemented using threads, or some other =
paradigm that avoids</FONT>

<BR><FONT SIZE=3D2>&gt; process creation and destruction per connection, =
the fact remains that</FONT>

<BR><FONT SIZE=3D2>&gt; the very act of creating a socket connection is =
expensive on most</FONT>

<BR><FONT SIZE=3D2>&gt; current OS's. Maybe someday these limitations =
will also disappear, but</FONT>

<BR><FONT SIZE=3D2>&gt; that doesn't mean that the problem doesn't exist =
today and isn't worth</FONT>

<BR><FONT SIZE=3D2>&gt; providing for.</FONT>
</P>

<P><FONT SIZE=3D2>I guess I have a REALLY hard time believing that the =
cost of creating/destroying a socket is significant relative to the cost =
of actually performaing the relative IMAP operations.&nbsp; And if it =
IS, I further claim that the platform itself is broken and should be =
considered as an inappropriate platform for a high performance =
server.&nbsp; See my Socratic dialogue below.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; (3) The servers that could benefit from this =
proposal would </FONT>

<BR><FONT SIZE=3D2>&gt; implement it.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Sorry to disappoint you, Mark. You need to look =
at this from total</FONT>

<BR><FONT SIZE=3D2>&gt; system perspective. It's not the servers that =
would benefit from the</FONT>

<BR><FONT SIZE=3D2>&gt; proposal, but instead embedded systems acting as =
IMAP clients. These</FONT>

<BR><FONT SIZE=3D2>&gt; clients are using the IMAP servers in certain =
fashions of which you</FONT>

<BR><FONT SIZE=3D2>&gt; haven't yet considered all the ramifications. =
Marko's example of a web</FONT>

<BR><FONT SIZE=3D2>&gt; based email service is such an embedded system. =
I work with developers</FONT>

<BR><FONT SIZE=3D2>&gt; of similar systems as well, and this type of =
extension has </FONT>

<BR><FONT SIZE=3D2>&gt; already being</FONT>

<BR><FONT SIZE=3D2>&gt; implemented for them. The &quot;combination of =
the client and server both</FONT>

<BR><FONT SIZE=3D2>&gt; supporting and using this extension&quot; =
definitely can benefit from the</FONT>

<BR><FONT SIZE=3D2>&gt; extension, and have already done so.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I'm going to take issue with even this =
statement.&nbsp; Lets work the logic out step by step.</FONT>
</P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When does this =
proposal benefit a platform?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the cost of =
establishing/receiving a connection is a significant percentage of the =
overall cost of the operation.&nbsp; There are no other cases where this =
is interesting.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When would the cost =
of RECEIVING a connection be a significant percentage of the cost (ie. =
on the Server)?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the design of the =
server software is one-process-per-user, or if the OS overhead of socket =
creation is too high.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are there any =
solutions other than this extension that resolve this?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes.&nbsp; As =
mentioned above, the IMAP server can be rewritten to use a model other =
than one-process-per-user.</FONT>
</P>

<P><FONT SIZE=3D2>So if this extension is still needed, it is likely to =
be some requirement of the CLIENT, not the server that is driving it =
(since the server side can be fixed).</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When would the cost =
of ESTABLISHING a connection be a significant percentage of the cost =
(ie. on the Client)?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the client OS =
software makes it expensive - it might have to dial a modem, etc.&nbsp; =
But that begs the next question:</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Would this extension =
help this case?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No - what CLIENTS =
would be simultaneously supporting multiple users?&nbsp; Certainly not =
handheld devices or PCs.&nbsp; The only case where a CLIENT =
simultaneously supports multiple users is in the case of a proxy client =
of one form or another.</FONT></P>

<P><FONT SIZE=3D2>So this extension is really targeted at improving the =
efficiency of proxy servers (yes, I know this was a long road to go =
through to get back to what Marko mentioned in his initial mail, but =
please bear with me, I'm actually going somewhere with this).</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So what is it about a =
proxy server that makes this extension necessary?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nothing - proxy =
servers can establish a connection that lasts as long as the client =
connection, so this isn't a big deal.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; But what if the =
client connection is NOT as long as the server connection?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ahhh...&nbsp; That =
must be it.&nbsp; The server in question must in fact be an HTTP gateway =
backed by IMAP.&nbsp; Since HTTP is a connectionless protocol, the =
server must be reestablishing the IMAP connection on EVERY incoming HTTP =
request.&nbsp; In such an environment, the connection establishment time =
CAN start to overwhelm the operational cost, since you will be executing =
at most one authenticated IMAP verb for each HTTP request.</FONT></P>

<P><FONT SIZE=3D2>Why did I just waste all that time getting to this =
place?&nbsp; To point out that there is only ONE case where this =
extension is of real benefit (which is confirmed by Tony and Marko's =
mail).&nbsp; And that case is where you have an HTTP-&gt;IMAP proxy =
server that is written on HTTP 1.0.&nbsp; If it was written using HTTP =
1.1, it would be possible to use fact that HTTP 1.1 is (sort-of) =
connection oriented to avoid continually reestablishing the connection =
with the IMAP server.</FONT></P>

<P><FONT SIZE=3D2>My claim is that even if you use HTTP 1.0, you can put =
enough context in your URLs to allow you to use only one connection per =
HTTP CLIENT when talking to the server (as opposed to one connection per =
HTTP VERB).&nbsp; You already have to cache the users&nbsp; =
authorization credentials on the server (or you force the user to =
reauthenticate on every click), you can use this cache to hold your =
cached connection state.</FONT></P>

<P><FONT SIZE=3D2>&gt; No, it's not something that most clients will =
utilize, nor is it</FONT>

<BR><FONT SIZE=3D2>&gt; something that all servers need implement. But =
in some </FONT>

<BR><FONT SIZE=3D2>&gt; contexts, such as</FONT>

<BR><FONT SIZE=3D2>&gt; the web-based email service mentioned by =
Marko,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it is extremely useful =
in those contexts</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it's already been =
implemented differently in at least two</FONT>

<BR><FONT SIZE=3D2>&gt; implementations</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it's worth =
standardizing on a single syntax</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o (from the draft) =
&quot;persistent IMAP4 connections can lead to a</FONT>

<BR><FONT SIZE=3D2>&gt; performance increase of an order of magnitude =
when compared </FONT>

<BR><FONT SIZE=3D2>&gt; to separate</FONT>

<BR><FONT SIZE=3D2>&gt; IMAP4 connections per mailbox =
action&quot;</FONT>
</P>

<P><FONT SIZE=3D2>If this is the case, then this should be submitted an =
experimental or informational extension and NOT standards track =
extension.&nbsp; You're going to have a REALLY hard time finding =
interoperable implementations if it's only implemented in your =
propriatary code bases.</FONT></P>

</BODY>
</HTML>
------=_NextPart_000_30267_01BF10D4.F0B750C0--

Date: Thu, 07 Oct 1999 17:17:07 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Mark Crispin wrote:
> 
> I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
> already defines an excellent multiplexing facility: TCP.  You are going to
> encounter enormous opposition to duplicating TCP's work, especially in the
> name of working around poorly-designed operating systems.

Red herring. It's not reinventing multiplexing. It's introducing
serialization at the application level within the context of an existing
TCP connection. No duplication of TCP's work is happening.

This is totally comparable to issuing another MAIL FROM to an SMTP
connection after the first message's DATA block is sent. This feature is
used by SMTP systems around the world today for the same reason: to
avoid establishing a new socket between messages.

> As an ATT shareholder, I am very concerned about your report that ATT may be
> deploying "IMAP" software that only works with ATT software.  Can you assure
> us that ATT's "embedded systems" will interoperable with standard IMAP
> software?

As I said, it's a private extension. If the extension shows up in the
capabilities list, things work much faster. If the extension doesn't
show up in the capabilities list, you're back to the existing slow state
of dropping the connection and starting up a new connection.

	Tony Hansen
	[email-masked]

To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Date: Thu, 07 Oct 1999 15:06:24 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>>>>> "Tony" == Tony Hansen <[email-masked]> writes:

    Tony> Lyndon wrote:
    >> There's another problem with this. It's not going to work in
    >> the presence of SASL session integrity or protection. There's
    >> no provision in 2060 for turning either of these off once
    >> they've been established, and I don't see how an extension
    >> could change the base spec in a manner that allowed this
    >> without resetting the standards-track clock.

    Tony> Lawrence's reply answers this objection sufficiently:
    >> The SASL specification says that a layer ends when another
    >> layer is turned on, ....

No it doesn't. SASL may provide a mechanism, but 2060 doesn't. 2060
would have to be changed to explicitly call out the behaviour during
the state change. I.e., when exactly is integrety/protection turned
off?

Allowing an IMAP session to switch out of authenticated state
(in any manner) seems to me to be a fundamental change to the semantics
of the protocol. It's not extending the protocol, it's changing it.
I don't think the IETF standards process allows us to do this.

    Tony> No, it's not something that most clients will utilize, nor
    Tony> is it something that all servers need implement. But in some
    Tony> contexts, such as the web-based email service mentioned by
    Tony> Marko,

The web server is just another IMAP client. It can, and should, cache
IMAP connections just like any other IMAP client would.

--lyndon

Date: Thu, 7 Oct 1999 13:49:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-karppinen-imap-conman-00.txt
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Tony -

I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
already defines an excellent multiplexing facility: TCP.  You are going to
encounter enormous opposition to duplicating TCP's work, especially in the
name of working around poorly-designed operating systems.

As an ATT shareholder, I am very concerned about your report that ATT may be
deploying "IMAP" software that only works with ATT software.  Can you assure
us that ATT's "embedded systems" will interoperable with standard IMAP
software?

-- Mark --

Date: Thu, 07 Oct 1999 14:49:39 -0600
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Lyndon Nerenberg wrote:

> There's another problem with this. It's not going to work in
> the presence of SASL session integrity or protection. There's
> no provision in 2060 for turning either of these off once they've
> been established,

Exactly. Currently IMAP SASL profile doesn't allow to clear SASL state.
RFC 2222 (SASL), says:

    5.3.  Multiple authentications

       Unless otherwise stated by the protocol's profile, only one
       successful SASL negotiation may occur in a protocol session.  In
this
       case, once an authentication protocol exchange has successfully
       completed, further attempts to initiate an authentication
protocol
       exchange fail.

Alexey

Date: Thu, 07 Oct 1999 16:20:24 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Marko Karppinen wrote:
>
> I'm just writing to let you all know that a new extension to the
> IMAP4 protocol is being proposed in our new Internet-Draft,
> available from:
> http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt
> The basic idea is to allow multiple user sessions during a
> single socket connection to an IMAP4 server. The context
> in which this proved to be neccessary involves internal
> components of a web based email service. However special
> our application may seem, we at Icon Medialab and Chek believe
> that standardizing this sort of functionality before it gets
> implemented in various different ways is in everyone's interests.

In a similar context, we were forced to implement a private extension
almost exactly like USERLOGOUT and have found it EXTREMELY useful. We'd
love to switch to a standard name for the capability.

So far, the arguments I've seen against it seem somewhat specious.

Larry wrote:
> For example, there's no requirement that you run the
> IMAP server in a "one-process-per-connection" mode.
Mark wrote:
> The problem is that the perceived need for this facility in IMAP is based upon
> two assumptions:
>  1) The IMAP protocol requires one process per connection.

No, there's no such assumption in this extension. The two concepts are
totally orthogonal. Each IMAP connection is a totally separate entity,
in and of itself, whether it maps into a thread on the server, or a
process, or whatever. Being able to manage those connections in a way
that lets the client reuse them is useful, for SOME CLIENTS.

> 2) The costs of creating and destroying a process per connection are high.
>
> Assumption (2) also has clay feet; process creation/destruction is slow
> because OS vendors have never felt the need to fix it.

Bad assumption in the counter argument, as this may not have anything to
do with creating and destroying a process per connection. If the server
were implemented using threads, or some other paradigm that avoids
process creation and destruction per connection, the fact remains that
the very act of creating a socket connection is expensive on most
current OS's. Maybe someday these limitations will also disappear, but
that doesn't mean that the problem doesn't exist today and isn't worth
providing for.

> There's a third assumption, which is completely false and fatal to the
> proposal:
> (3) The servers that could benefit from this proposal would implement it.

Sorry to disappoint you, Mark. You need to look at this from total
system perspective. It's not the servers that would benefit from the
proposal, but instead embedded systems acting as IMAP clients. These
clients are using the IMAP servers in certain fashions of which you
haven't yet considered all the ramifications. Marko's example of a web
based email service is such an embedded system. I work with developers
of similar systems as well, and this type of extension has already being
implemented for them. The "combination of the client and server both
supporting and using this extension" definitely can benefit from the
extension, and have already done so.

Lyndon wrote:
> There's another problem with this. It's not going to work in
> the presence of SASL session integrity or protection. There's
> no provision in 2060 for turning either of these off once they've
> been established, and I don't see how an extension could change
> the base spec in a manner that allowed this without resetting the
> standards-track clock.

Lawrence's reply answers this objection sufficiently:
> The SASL specification says that a layer ends when another layer is
> turned on, ....

No, it's not something that most clients will utilize, nor is it
something that all servers need implement. But in some contexts, such as
the web-based email service mentioned by Marko,

    o	it is extremely useful in those contexts

    o	it's already been implemented differently in at least two
implementations

    o	it's worth standardizing on a single syntax

    o	(from the draft) "persistent IMAP4 connections can lead to a
performance increase of an order of magnitude when compared to separate
IMAP4 connections per mailbox action"

	Tony Hansen
	[email-masked]

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt 
Date: Thu, 7 Oct 1999 11:26:28 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2A01F_01BF10B6.CE534840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In general, "proxy" is virtually indistinguishable from "tunneling", and
it is almost always a bad idea.  The only place that I know of where
tunneling is reasonable is when passing through a firewall, otherwise
it's a nightmare.  And I know of NO situation where tunneling increases
scalability, because the throughput is almost always limited by the
throughput of the proxy server.

What is more interesting w.r.t. scalability is the Front-End/Back-End
scenario where the client talks to one of several front-end machines
each of which shares the same DNS A record (ie imap.myisp.net).  The
front-end machine then uses some protocol (possibly IMAP, possibly CIFS,
possibly NFS) to talk to the actual message store.  A solution of this
nature allows 2-way scalability without impacting the client - if you
overload your front-end machines, you can simply add more without
changing client configuration, similarly, if you find you are
overloading your back-end servers, you can again add more of them if
necessary.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lawrence Greenfield
> Sent: Thursday, October 07, 1999 11:11 AM
> To: [email-masked]; [email-masked]
> Subject: Re: draft-karppinen-imap-conman-00.txt=20
>=20
>=20
>    There's another problem with this. It's not going to work in
>    the presence of SASL session integrity or protection. There's
>    no provision in 2060 for turning either of these off once they've
>    been established, and I don't see how an extension could change
>    the base spec in a manner that allowed this without resetting the
>    standards-track clock.
>=20
> The SASL specification says that a layer ends when another layer is
> turned on, but that doesn't help with the other problems.
>=20
>    As Barry said, deficiencies in the implementation should be fixed
>    in the implementation. (I can say that, because we just=20
> went through
>    this specific exercise :-)=20
>=20
> I've considered adding a PROXY command so that a suitably privileged
> user can do something like:
>=20
> A001 PROXY leg LIST "" "*imap*"
>=20
> for some thoughts I've had about IMAP proxys to help with scalability,
> I've come to the conclusion that almost any of this is best done
> outside of the protocol.  The PROXY command would be a pain (without
> adding that much) to work with SELECT or any more complicated commands
> than LIST, etc.
>=20
> Larry
>=20

------=_NextPart_000_2A01F_01BF10B6.CE534840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>In general, &quot;proxy&quot; is virtually =
indistinguishable from &quot;tunneling&quot;, and it is almost always a =
bad idea.&nbsp; The only place that I know of where tunneling is =
reasonable is when passing through a firewall, otherwise it's a =
nightmare.&nbsp; And I know of NO situation where tunneling increases =
scalability, because the throughput is almost always limited by the =
throughput of the proxy server.</FONT></P>

<P><FONT SIZE=3D2>What is more interesting w.r.t. scalability is the =
Front-End/Back-End scenario where the client talks to one of several =
front-end machines each of which shares the same DNS A record (ie =
imap.myisp.net).&nbsp; The front-end machine then uses some protocol =
(possibly IMAP, possibly CIFS, possibly NFS) to talk to the actual =
message store.&nbsp; A solution of this nature allows 2-way scalability =
without impacting the client - if you overload your front-end machines, =
you can simply add more without changing client configuration, =
similarly, if you find you are overloading your back-end servers, you =
can again add more of them if necessary.</FONT></P>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-imapext@imc.=
org</A>]On</FONT>

<BR><FONT SIZE=3D2>&gt; Behalf Of Lawrence Greenfield</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, October 07, 1999 11:11 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-karppinen-imap-conman-00.txt =
</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; There's another problem with =
this. It's not going to work in</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the presence of SASL session =
integrity or protection. There's</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; no provision in 2060 for =
turning either of these off once they've</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; been established, and I don't =
see how an extension could change</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the base spec in a manner that =
allowed this without resetting the</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; standards-track clock.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The SASL specification says that a layer ends =
when another layer is</FONT>

<BR><FONT SIZE=3D2>&gt; turned on, but that doesn't help with the other =
problems.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; As Barry said, deficiencies in =
the implementation should be fixed</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; in the implementation. (I can =
say that, because we just </FONT>

<BR><FONT SIZE=3D2>&gt; went through</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; this specific exercise :-) =
</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I've considered adding a PROXY command so that a =
suitably privileged</FONT>

<BR><FONT SIZE=3D2>&gt; user can do something like:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; A001 PROXY leg LIST &quot;&quot; =
&quot;*imap*&quot;</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; for some thoughts I've had about IMAP proxys to =
help with scalability,</FONT>

<BR><FONT SIZE=3D2>&gt; I've come to the conclusion that almost any of =
this is best done</FONT>

<BR><FONT SIZE=3D2>&gt; outside of the protocol.&nbsp; The PROXY command =
would be a pain (without</FONT>

<BR><FONT SIZE=3D2>&gt; adding that much) to work with SELECT or any =
more complicated commands</FONT>

<BR><FONT SIZE=3D2>&gt; than LIST, etc.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Larry</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_2A01F_01BF10B6.CE534840--

Date: Thu, 7 Oct 1999 10:08:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
To: [email-masked]
cc: [email-masked]
Sender: [email-masked]

Unfortunately, I have to concur with Larry and Lyndon.

Internet history is littered with ideas that were technically excellent and
would have provided a useful facility, but were nonetheless unsuccessful.  I'm
afraid this is one of them.  This is not the first time this idea has been
proposed for IMAP, but the same reluctant conclusion resulted.

The problem is that the perceived need for this facility in IMAP is based upon
two assumptions:
 1) The IMAP protocol requires one process per connection.
 2) The costs of creating and destroying a process per connection are high.

If either assumption is false, the need collapses.  Examples can be found that
demonstrate either (or both) assumption(s), but that does not mean that the
assumptions are valid in all cases.

As Larry and Lydon have pointed out, assumption (1) is particularly weak.

Assumption (2) also has clay feet; process creation/destruction is slow
because OS vendors have never felt the need to fix it.  I can guarantee that
if a multi-billion dollar contract for Microsoft depended upon fast process
management, the next version of NT would be blindingly fast.  ;-)  Another way
around this would be if the operating system allowed process recycling; that
is, instead of the process being destroyed upon log out, that it be permitted
to place itself into a "standby" state.  In "standby", it regains root and is
suspended at its start address.  [Leaving aside the small matter of
programming here...but implementing conman would also require programming, and
in every client and server for every affected protocol.]

There's a third assumption, which is completely false and fatal to the
proposal:
 (3) The servers that could benefit from this proposal would implement it.

Unfortunately, this won't happen.  In the case of my server, it won't happen.
The entire security model of my server depends upon one process per
connection; servers setuid() themselves to the target user to discard their
root privileges irrecoverably, and all access control is done by file system
protections.

In order to implement conman, I would have to create an entirely different
security model.  But if I did that, there would be no reason to maintain the
current "one process per connection" other than laziness.  If I am lazy, I
wouldn't implement conman; if I am not lazy, I'd use a architecture such as
threading and conman would be unnecessary.

In conclusion, conman is unnecesary in those servers in which it would be
relatively easy to implement it; in the servers which conman would benefit, it
is incredibly difficult to implement and it would be easier to solve the
problem with a different server architecture.  Plus, a different server
architecture would not require any client changes.

Date: 7 Oct 1999 14:11:17 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Sender: [email-masked]

   There's another problem with this. It's not going to work in
   the presence of SASL session integrity or protection. There's
   no provision in 2060 for turning either of these off once they've
   been established, and I don't see how an extension could change
   the base spec in a manner that allowed this without resetting the
   standards-track clock.

The SASL specification says that a layer ends when another layer is
turned on, but that doesn't help with the other problems.

   As Barry said, deficiencies in the implementation should be fixed
   in the implementation. (I can say that, because we just went through
   this specific exercise :-) 

I've considered adding a PROXY command so that a suitably privileged
user can do something like:

A001 PROXY leg LIST "" "*imap*"

for some thoughts I've had about IMAP proxys to help with scalability,
I've come to the conclusion that almost any of this is best done
outside of the protocol.  The PROXY command would be a pain (without
adding that much) to work with SELECT or any more complicated commands
than LIST, etc.

Larry

To: [email-masked], [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Date: Thu, 07 Oct 1999 11:21:09 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

There's another problem with this. It's not going to work in
the presence of SASL session integrity or protection. There's
no provision in 2060 for turning either of these off once they've
been established, and I don't see how an extension could change
the base spec in a manner that allowed this without resetting the
standards-track clock.

As Barry said, deficiencies in the implementation should be fixed
in the implementation. (I can say that, because we just went through
this specific exercise :-) 

--lyndon

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Thu, 7 Oct 1999 10:04:57 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_27A1E_01BF10AB.6E0F9430
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I might humbly suggest that there are easier ways of acheiving your
desired goals than extending the protocol.  For example, there's no
requirement that you run the IMAP server in a
"one-process-per-connection" mode.  This DOES simplify some aspects of
the IMAP logic, but (as you have noted) the costs of creating and
destroying a process per connection can be overwhelming.

There are alternative models for the networking logic that do not
require one process per connection, for example, you could use a thread
per connection, or (if your platform supports it) use an asynchronous
I/O which allows a few threads to process all the I/O for your client.
I would strongly encourage you to investigate these possibilities,
otherwise I suspect that you will discover that you STILL have
performance issues, all this change does is to move the choke-point
location.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marko Karppinen
> Sent: Thursday, October 07, 1999 8:25 AM
> To: [email-masked]
> Subject: draft-karppinen-imap-conman-00.txt
>=20
>=20
> Hi,
>=20
> I'm just writing to let you all know that a new extension to the
> IMAP4 protocol is being proposed in our new Internet-Draft,
> available from:
>=20
> http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt
>=20
> The basic idea is to allow multiple user sessions during a
> single socket connection to an IMAP4 server. The context
> in which this proved to be neccessary involves internal
> components of a web based email service. However special
> our application may seem, we at Icon Medialab and Chek believe
> that standardizing this sort of functionality before it gets
> implemented in various different ways is in everyone's interests.
>=20
> We hope our Internet-Draft is a good starting point in discussing
> the need and possible implementations for this new functionality.
>=20
> Best regards,
>=20
> Marko Karppinen
> Icon Medialab
>=20
> On behalf of the authors
>=20
> --
> "Difficult to see, it is... always in motion is the future."
>=20

------=_NextPart_000_27A1E_01BF10AB.6E0F9430
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I might humbly suggest that there are easier ways of =
acheiving your desired goals than extending the protocol.&nbsp; For =
example, there's no requirement that you run the IMAP server in a =
&quot;one-process-per-connection&quot; mode.&nbsp; This DOES simplify =
some aspects of the IMAP logic, but (as you have noted) the costs of =
creating and destroying a process per connection can be =
overwhelming.</FONT></P>

<P><FONT SIZE=3D2>There are alternative models for the networking logic =
that do not require one process per connection, for example, you could =
use a thread per connection, or (if your platform supports it) use an =
asynchronous I/O which allows a few threads to process all the I/O for =
your client.&nbsp; I would strongly encourage you to investigate these =
possibilities, otherwise I suspect that you will discover that you STILL =
have performance issues, all this change does is to move the choke-point =
location.</FONT></P>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-imapext@imc.=
org</A>]On</FONT>

<BR><FONT SIZE=3D2>&gt; Behalf Of Marko Karppinen</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, October 07, 1999 8:25 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: =
draft-karppinen-imap-conman-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Hi,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I'm just writing to let you all know that a new =
extension to the</FONT>

<BR><FONT SIZE=3D2>&gt; IMAP4 protocol is being proposed in our new =
Internet-Draft,</FONT>

<BR><FONT SIZE=3D2>&gt; available from:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-0=
0.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-karppinen-ima=
p-conman-00.txt</A></FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The basic idea is to allow multiple user =
sessions during a</FONT>

<BR><FONT SIZE=3D2>&gt; single socket connection to an IMAP4 server. The =
context</FONT>

<BR><FONT SIZE=3D2>&gt; in which this proved to be neccessary involves =
internal</FONT>

<BR><FONT SIZE=3D2>&gt; components of a web based email service. However =
special</FONT>

<BR><FONT SIZE=3D2>&gt; our application may seem, we at Icon Medialab =
and Chek believe</FONT>

<BR><FONT SIZE=3D2>&gt; that standardizing this sort of functionality =
before it gets</FONT>

<BR><FONT SIZE=3D2>&gt; implemented in various different ways is in =
everyone's interests.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; We hope our Internet-Draft is a good starting =
point in discussing</FONT>

<BR><FONT SIZE=3D2>&gt; the need and possible implementations for this =
new functionality.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Best regards,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Marko Karppinen</FONT>

<BR><FONT SIZE=3D2>&gt; Icon Medialab</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On behalf of the authors</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; --</FONT>

<BR><FONT SIZE=3D2>&gt; &quot;Difficult to see, it is... always in =
motion is the future.&quot;</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_27A1E_01BF10AB.6E0F9430--

Date: Thu, 07 Oct 1999 18:24:47 +0300
From: Marko Karppinen <[email-masked]>
Reply-To: [email-masked]
Organization: Icon Medialab
To: [email-masked]
Subject: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Hi,

I'm just writing to let you all know that a new extension to the
IMAP4 protocol is being proposed in our new Internet-Draft,
available from:

http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt

The basic idea is to allow multiple user sessions during a
single socket connection to an IMAP4 server. The context
in which this proved to be neccessary involves internal
components of a web based email service. However special
our application may seem, we at Icon Medialab and Chek believe
that standardizing this sort of functionality before it gets
implemented in various different ways is in everyone's interests.

We hope our Internet-Draft is a good starting point in discussing
the need and possible implementations for this new functionality.

Best regards,

Marko Karppinen
Icon Medialab

On behalf of the authors

--
"Difficult to see, it is... always in motion is the future."

Date: Mon, 04 Oct 1999 18:23:59 -0600
From: Alexey Melnikov <[email-masked]>
To: Mike Gahrns <[email-masked]>
CC: [email-masked]
Subject: Re: Prohibitting enumaration of languages when specifying an extension
Sender: [email-masked]

Mike Gahrns wrote:

> *** Within
>
> > > >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> > > >       ; A client should not issue the optional extension parameter
> > > >       ; unless a server has indicated in its capabilities that it
> > > >       ; supports that extension
> > > >
> > > > I can't imagine any case when you want to use LANGUAGE command without
> > > specifying
> > > > language_tag. If somebody really wants this capability, I suggest to
> > > create new
> > > > command. So, my proposition is
> > > >
> > > > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> > > *** In earlier discussions, it was thought that being able to enumerate
> the
> > > languages available on the server would be helpful.  I agree, if at only
> for
> > > diagnosis purposes.
> >
> > I meant other case: Does something like "LANGUAGE (extension1 data1)"
> > make sense? What is the semantics of this command.
> *** I am not sure how this would be used, but thought that we shouldn't
> artificially limit this in case some extension wanted it.  e.g.   Give me
> the LIST of server languages that are supported by server, and then pass in
> the FOO extension parameter.  Perhaps the FOO extension without any tags
> would mean list in a response the languages you support for the FOO
> extension....

This make sense.

Alexey

From: "Mike Gahrns" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Subject: Prohibitting enumaration of languages when specifying an extension
Date: Mon, 4 Oct 1999 12:05:08 -0700
Sender: [email-masked]

*** Within

> > >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> > >       ; A client should not issue the optional extension parameter
> > >       ; unless a server has indicated in its capabilities that it
> > >       ; supports that extension
> > >
> > > I can't imagine any case when you want to use LANGUAGE command without
> > specifying
> > > language_tag. If somebody really wants this capability, I suggest to
> > create new
> > > command. So, my proposition is
> > >
> > > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> > *** In earlier discussions, it was thought that being able to enumerate
the
> > languages available on the server would be helpful.  I agree, if at only
for
> > diagnosis purposes.
>
> I meant other case: Does something like "LANGUAGE (extension1 data1)"
> make sense? What is the semantics of this command.
*** I am not sure how this would be used, but thought that we shouldn't
artificially limit this in case some extension wanted it.  e.g.   Give me
the LIST of server languages that are supported by server, and then pass in
the FOO extension parameter.  Perhaps the FOO extension without any tags
would mean list in a response the languages you support for the FOO
extension....

Date: Mon, 4 Oct 1999 11:25:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
To: Alexey Melnikov <[email-masked]>
cc: Mike Gahrns <[email-masked]>, [email-masked]
Sender: [email-masked]

Although I understand the motivation for the TRANSLATION extension to
NAMESPACE, I feel that there is a major problem with it.

The example shows a namespace called "Other Users/" with a translation of
"Autres Utilisateurs/".  Leaving aside the bogosity of the missing "#"
(particularly in light of the personal namespace), this example is going to
give certain individuals a strong feeling that "Autres Utilisateurs/" is a
valid namespace name.  This, in turn, implies that it is valid to use it in
URLs.

I strongly oppose localization of strings that could appear in a mailbox name
and/or a URL.  It's enough of a problem that they can be internationalized.

I suggest instead that we add a field in namespace called COMMENT or
DESCRIPTION, and that this new field can be localized.  This opens the
possibility for this field to be English; #public/ and #shared/ are very two
different things in my server, but that fact is not obvious from those names.

Since this no longer changes the namespace names, the draft can be simplied
and the troublesome rules between LANGUAGE and NAMESPACE can be deleted.

This has another desirable effect.  It may break client implementors of the
deplorable habit of treating the NAMESPACE command as simply another level of
hierarchy to a common root.  I've learned not to underestimate the grim
determination of certain client vendors to do the wrong thing in the face of
intense pressure from the specification otherwise. ;-)  But, maybe by having
the localized string as a comment, it may tip the balance towards treating
namespaces as independent hierarchies.

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Oct 1999 11:21:12 -0600
To: Mike Gahrns <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 4 Oct 1999 08:07:44 -0700 Mike Gahrns <[email-masked]> 
wrote:

> Hi Alexey,
> 
> *** Comments within.
> 
> P.S.  I will have very limited access to e-mail the next 2.5 weeks, so I
> will be slow in responding to any comments.
> 
> 
> 
> > Hi Mike,
> >
> > Here is some comments about the last draft:
> >
> >    1). If server supports both LANGUAGE and NAMESPACE it MUST return
> NAMESPACE
> > response:
> > I would rather replace MUST with SHOULD, because when you describe
> TRANSLATION, you
> > says that
> > TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't
> be sent and
> > NAMESPACE hasn't been changed - why send NAMESPACE response at all?
> *** To make it a MUST was a request I receivedd on the previous draft.  The
> rational was that it made it slightly easier for clients if they knew to
> always expect a NAMESPACE response (if the server supports NAMESPACE).  I
> don't have strong feelings here, either way, but tend to agree that always
> sending the response could make things simpler.
>

I don't mind, but draft should state that explicitely.
Without this comment "MUST" doesn't make sense.
  
> >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> >       ; A client should not issue the optional extension parameter
> >       ; unless a server has indicated in its capabilities that it
> >       ; supports that extension
> >
> > I can't imagine any case when you want to use LANGUAGE command without
> specifying
> > language_tag. If somebody really wants this capability, I suggest to
> create new
> > command. So, my proposition is
> >
> > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> *** In earlier discussions, it was thought that being able to enumerate the
> languages available on the server would be helpful.  I agree, if at only for
> diagnosis purposes.

I meant other case: Does something like "LANGUAGE (extension1 data1)" 
make sense? What is the semantics of this command.

> >    4). Primary language: Accordingly to Alvestrand RFC language tag is not
> always
> > hierarchical. This means that you can't always assume that x-y-z is
> sublanguage of x-y.
> > This means that server should have some additional knowledge about
> languages it
> > supports.
> *** Can you suggest some text to address this?

Yes, I will.
---------------
Alexey Melnikov
Software Developer    phone: (780) 424 4922 x 357
MessagingDirect Ltd.  fax  : (780) 424 4925

mailto:[email-masked]
http://www.MessagingDirect.com

* This e-mail message was sent with Execmail V5.0 *

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
Date: Mon, 4 Oct 1999 08:07:44 -0700
Sender: [email-masked]

Hi Alexey,

*** Comments within.

P.S.  I will have very limited access to e-mail the next 2.5 weeks, so I
will be slow in responding to any comments.

> Hi Mike,
>
> Here is some comments about the last draft:
>
>    1). If server supports both LANGUAGE and NAMESPACE it MUST return
NAMESPACE
> response:
> I would rather replace MUST with SHOULD, because when you describe
TRANSLATION, you
> says that
> TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't
be sent and
> NAMESPACE hasn't been changed - why send NAMESPACE response at all?
*** To make it a MUST was a request I receivedd on the previous draft.  The
rational was that it made it slightly easier for clients if they knew to
always expect a NAMESPACE response (if the server supports NAMESPACE).  I
don't have strong feelings here, either way, but tend to agree that always
sending the response could make things simpler.

>
>    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
>       ; A client should not issue the optional extension parameter
>       ; unless a server has indicated in its capabilities that it
>       ; supports that extension
>
> I can't imagine any case when you want to use LANGUAGE command without
specifying
> language_tag. If somebody really wants this capability, I suggest to
create new
> command. So, my proposition is
>
> LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
*** In earlier discussions, it was thought that being able to enumerate the
languages available on the server would be helpful.  I agree, if at only for
diagnosis purposes.

>
>    3). EXTENSION = SP "(" string SP "(" string *(SP string)")" ")"
>
> I suspect that first parameter in the list is LANGUAGE extension name. I
prefer to
> mention that.
**** this is correct and I good suggestion I will incorporate into a future
revision

>
>    4). Primary language: Accordingly to Alvestrand RFC language tag is not
always
> hierarchical. This means that you can't always assume that x-y-z is
sublanguage of x-y.
> This means that server should have some additional knowledge about
languages it
> supports.
*** Can you suggest some text to address this?

>
>    5). Does TRANSLATION NAMESPACE extension eliminates the need to change
namespace
> prefixes?
*** Yes, that is the idea.  (this would allow for things like preserving
urls across messages, and leave it up to the client to translate namespaces
if necessary)

> I would suggest adding something like "SHOULD NOT change namespace prefix"
*** I can add this.

>
>
> Alexey
>

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-gahrns-imap-language-01.txt
Date: Mon, 04 Oct 1999 07:08:15 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 Language Extension
	Author(s)	: M. Gahrns
	Filename	: draft-gahrns-imap-language-01.txt
	Pages		: 8
	Date		: 01-Oct-99
	
The Internet Message Access Protocol [RFC-2060] allows server 
responses to include human-readable text that in many cases needs to 
be presented to the user.  This document specifies a way for a 
client to negotiate which language the server should use when 
sending human-readable text.  It provides an extensible mechanism so 
that it may be used as a framework for full internationalization of 
other IMAP extensions such as SORT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gahrns-imap-language-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-language-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 28 Oct 1999 13:48:16 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-01.txt (fwd)
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 10/28/99 at 2:37 PM -0400, Cyrus Daboo wrote:

>PS This got delayed because I originally submitted it under 
>draft-ietf-imapext but the document editors claimed there was no 
>such WG. I think we need to get this straightened out!

Yes, this was my fault. I got the charter in too late for Keith and 
Patrik to bring it to the IESG for approval before the meeting in DC. 
We will be a WG soon, I promise.

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

Date: Thu, 28 Oct 1999 14:37:41 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imap-view-01.txt (fwd)
Sender: [email-masked]

--==========00575812==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
An updated VIEW extension draft is available at the IETF drafts repository
as indicated below. This is the second version of the VIEW extension draft
and incorporates changes discussed on the list and at the last meeting in
Oslo. I've attached another text part to this message listing the changes
made between -00 and -01.

Note that the issue of static vs semi-dynamic vs fully dynamic updates is
still undecided (at least that's the impression I got after the last round
of messages on that topic) so this was not changed in the draft, which
still describes a fully dynamic mechanism. I suggest this be one of the
main items on the agenda for the WG meeting in a couple of weeks.

PS This got delayed because I originally submitted it under
draft-ietf-imapext but the document editors claimed there was no such WG. I
think we need to get this straightened out!

---------- Forwarded Message ----------
Date: Thursday, October 28, 1999 7:08 AM -0400
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imap-view-01.txt

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

	 Title		: IMAP VIEW Extension
	 Author(s)	: C. Daboo, M. Pustilnik, M. Crispin
	 Filename	: draft-daboo-imap-view-01.txt
	 Pages		: 14
	 Date		: 27-Oct-99
	 
The VIEW extension to the Internet Message Access Protocol [IMAP4]
permits a subset of messages in the mailbox to be processed
separately from the entire set of messages in the mailbox.  This
allows a client to restrict its view to only the messages appearing
in this set.  The subset of messages also need not be returned in
order of their sequence numbers, allowing clients to access messages
in a particular sort order.

---------- End Forwarded Message ----------

--
Cyrus
--==========00575812==========
Content-Type: text/plain; charset=us-ascii; name="view_changes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="view_changes.txt"; size=3068

View Draft Changes

General
- Added option to allow VIEW SET command arguments during a SELECT or
EXAMINE command as agreed in Olso.
- Changed text to describe VIEW as a single command and a single response,
with different variants.

3 Introduction
- (c) removed VIEW item in FETCH command as there is never any need to
explicitly request it as its always returned when view is in effect.

4.1 VIEW SET Command
- Added clarification on valid sub-commands: only SEARCH for now but may
allow SORT and THREAD in future.
- (c) changed to apply to ALL fetch responses not just unsolicited.
- (c) removed reference to VIEW item in FETCH command.
- Added (h) to clarify resetting a view using another VIEW SET.
- Added (i) to clarify cancellation of a view if SELECT, EXAMINE or CLOSE
occur.

4.3 (was 4.2) VIEW Command
- Added statement that VIEW command is only valid when VIEW SET in effect.

5.1.1
- Removed previous restriction on not sending VIEW response when no command
is in effect. This contradicts the requirement that VIEW responses for new
messages must be sent after an EXISTS.

5.1.2
- Clarified restrictions on when VIEW response for moving messages can be
sent.
- Corrected 'non-zero' to 0 in a couple of places.
- Added section on both <old> and <new> being non-zero.
- Corrected examples which had <new> and <old> values reversed.

6
- Revised to be compliant with RFC2234.
- Modified syntax to reflect VIEW as a single command and response.
- Added syntax for modified SELECT and EXAMINE commands.
- Added msg-att-dynamic for VIEW message data item in FETCH.
- Alphabetic sort of formal syntax terms.

--==========00575812==========--

Date: Wed, 13 Oct 1999 14:32:12 -0600
From: Alexey Melnikov <[email-masked]>
To: Mike Gahrns <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: draft-gahrns-imap-language-01
Sender: [email-masked]

Alexey Melnikov wrote:

> > >    4). Primary language: Accordingly to Alvestrand RFC language tag is not
> always
> > > hierarchical. This means that you can't always assume that x-y-z is
> sublanguage of x-y.
> > > This means that server should have some additional knowledge about languages
> it
> > > supports.
> > *** Can you suggest some text to address this?

Ok, let me do the first try (BTW, I am referencing
draft-alvestrand-lang-tags-v2-00.txt, not RFC 1766):

>4. LANGUAGE Command
>
>   Arguments: Zero or one language tag as defined by [RFC-1766].

Add the following text: "Language tags MUL (Multiple languages) and Und
(Undetermined) MUST NOT be used."
Same text should be added to ABNF section.

After the text

>             If a sublanguage was asked for and not available but the
>             primary language is available, the server should switch to
>             the primary language and include a LANGUAGE response
>             containing the identifier of the primary language it
>             switched to.

add the following:

It is also recommended that server recognizes languages that have multiple
different tags (like "ru" and "rus").

Note 1. Client MUST NOT use MUL (Multiple languages) and Und (Undetermined)
language tags and server MUST return BAD to the LANGUAGE command with such
parameter.

Note 2. [LANG-TAG] (draft-alvestrand-lang-tags-v2-00.txt) warns that there is no
guaranteed relationship between languages whose tags start out with the same
series of subtags. However it is believed that for the purpose of this document it
is safe to treat all languages, whose tags starts with primary language described
in ISO 639-1 and ISO 639-2 (i.e. all 2 or 3 letters primary languages) as
hierarchical. For all languages with other primary tags fallback rule MUST not be
used. In particular, language tags starting with 'i-' and 'x-' SHOULD NOT be
treated as hierarchical.
---------------
Alexey Melnikov
Software Developer    phone: (780) 424 4922 x 357
MessagingDirect Ltd.  fax  : (780) 424 4925

mailto:[email-masked]
http://www.MessagingDirect.com

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Cc: "Pristin, Dmitry" <[email-masked]>, "Neystadt, John" <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Sat, 9 Oct 1999 16:53:53 +0200 
Sender: [email-masked]

> From: Larry Osterman (Platinum) [mailto:[email-masked]]
> Sent: Friday, October 08, 1999 12:02 AM
> To: Tony Hansen; [email-masked]
> Subject: RE: draft-karppinen-imap-conman-00.txt
> 
> 
> Comments within, but warning - they are a bit long, but I 
> think relevant. 

The comments are (IMHO) very relevant. I was even moved to write a response,
which I initially had no inclination of doing.

> I guess I have a REALLY hard time believing that the cost of 
> creating/destroying a socket is significant relative to the 
> cost of actually performaing the relative IMAP operations.  

Exactly. Which leads to the conclusion: HTTP thingies that are IMAP clients
will suffer much greatly from the initial IMAP commands than from the socket
connection. On each HTTP transaction the CGI script (or ASP, or whatever
there is) will have to issue the following set of commands (or a similar
one):

LOGIN/AUTHENTICATE (can be pretty slow, if the authentication performed
against a busy, remote authentication server)
SELECT something (can be pretty slow when the mailbox is large and it's a
remote one, say, another IMAP client)
FETCH 1:* (UID FLAGS)

I'm pretty sure the penalty of issuing these commands is greater than that
of creating a new connection. Especially if you work in a thread-per-session
or constant-number-of-threads modes. We've also encountered this problem
while trying to make our IMAP server work as an HTTP back end. Our solution
is different (and it has already been implemented). It's goal is to solve
the problem of initial synchronization with the server.

The following two commands are introduced: X-CNS-LOGOUT, X-CNS-LOGIN. 

The CGI script, once finished fetching the relevant data, issues the
X-CNS-LOGOUT command. The response includes a session ID, which is unique
per something (say, lifetime of the server). The server then disconnects the
client, while keeping all of the session's state. On the next HTTP
transaction, the CGI script connects to the IMAP server and issues the
X-CNS-LOGIN command, passing on the session ID as a parameter. The session's
state is then restored. Once the HTTP client issues a logout (or on other
circumstances, when the session is considered over), the IMAP client issues
the usual LOGOUT command and the session's state is then scraped.

Basically, what it does is caches IMAP session instead of forcing the client
to do that. If the server is implemented in an efficient way, it may be
quite easy to implement.

That's it, in a nutshell. We've implemented this thing as a special proxy,
being reluctant for the moment to change the code of our IMAP server, but
the code can easily be incorporated into the server itself. There might be a
problem with load-balancing systems, that, perhaps, can be solved using IMAP
login referrals. Also there might be a security risk in using session IDs,
but this can be solved with ACLs. 

We never intended to publish this extension (as you might have noticed by
the 'X' in the command names), due to, mainly, lack of interest in the
community (as we saw it) and also, due to history of failed attempts at IMAP
standardization on our behalf. However, there seems to be certain interest
in the protocol driven solution to the problem of performance of IMAP
clients that are 'connectionless', and here we are. So, if someone else
finds this useful, we are willing to push it through.

--
Dmitry Rubinstein 

Date: Fri, 8 Oct 1999 15:12:17 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

A few points about all this.

LDAP, which otherwise uses SASL in a very similar manner to IMAP (since it
was following the example set by IMAP), has an Unbind operation (see RFC
2251 section 4.3) which is more or less identical to the proposed IMAP
USERLOGOUT command.  I believe this was part of the DAP command set that
was just carried over into LDAP.  But certainly as the LDAP authentication
details were being worked on (in draft-ietf-ldapext-ldapv3-tls-05.txt and
draft-ietf-ldapext-authmeth-04.txt) implementors made it known that being
able to de- and re-authenticate the connection was important to them, I
think for more or less the same reasons as the pro-USERLOGOUT folks give
here.  I have no idea how much this is used in practice.

The connection-reuse strategy proposed by the USERLOGOUT proponents is
similar to the "connection pooling" technique that is universally used, in
my experience, in 3-tier database-oriented apps these days, especially
those with a web front end (ie, all new ones).  A set of database
connections is created by the app-server at system startup time, and
connections are grabbed and released by app-server threads as needed.  
The authentication story is somewhat different than it would be with IMAP,
though, since generally the app-server authenticates to the database
service as itself at connection start time, and app-level authentication
identity is one of the parameters in each database op; so there isn't a
USERLOGOUT equivalent in this case.

So, there's certainly adequate precedent in other areas for the approach
proposed in this draft; I think the question at hand is whether this is
worth adding to a protocol that doesn't have it already.  I think what the
anti-USERLOGOUT implementors are saying is that if you came to them and
said that the performance cost of simply making a TCP connection is a
substantial fraction of the total cost of starting an authenticated
session, as is claimed in the draft:

   Initial profiling suggests
   that persistent IMAP4 connections can lead to a performance increase
   of an order of magnitude when compared to separate IMAP4 connections
   per mailbox action.

that they would scurry off and make it not be so, and that this is doable,
and should be done, without requiring any protocol changes.

So, this is a performance hack.  The only way to decide whether it's
justified is with numbers.  I think it's up to the proponents to post real
observed numbers; and then for the anti- implementors to refute them or do
the implementation mods to prove that the remediation can be done without
protocol mods.

As someone mentioned, adding this capability in the context of TLS makes
things even trickier.  Let me philosophize on this point.  TLS basically
has its own set of security states that can change more or less
independently of the application protocol (SASL) states; the job of the
profile is to tie these together appropriately.  We dealt with some of
this in the ldapv3-tls spec, see specifically section 7.2 which says that
ending a TLS connection undoes any authentication state in the LDAP
connection; but that the LDAP connection itself can continue after TLS is
stopped.  (RFC 2595 doesn't address this issue, which is an omission.)  
See

 http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.html

for an excellent state diagram of this behavior.  This is necessary to
specify the relevant behavior if you want TLS to be STOPpable as well as
STARTable.

Another look at RFC 2246 on TLS shows that at any time during a TLS
connection the handshake protocol can happen again, which can result in a
new set of security conditions and in particular a new client cert.  I
don't think any of the current app profiles for TLS take this into
account, even to the extent of saying "prohibited".  But if you wanted 
USERLOGOUT to work in the TLS+client_cert case (and surely this is an
increasingly important case) you'd probably say that *if* TLS is in use
and the client was authenticated via a cert, *then* USERLOGOUT would also
cause the server to issue a handshake protocol hello to renegotiate the
TLS authentication; or you might say that the TLS connection had to close,
but that's going to knock holes in the performance argument.

I find it hard to believe that performance gains (that aren't achievable
any other way) are enough to motivate USERLOGOUT as a standard facility,
given the non-trivial complexity of fully specifying (not to mention
implementing) the behavior it implies.

 - RL "Bob"

Date: Fri, 08 Oct 1999 09:40:58 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> Lyndon Nerenberg wrote:
> 
> > There's another problem with this. It's not going to work in
> > the presence of SASL session integrity or protection. There's
> > no provision in 2060 for turning either of these off once they've
> > been established,
> 
> Exactly. Currently IMAP SASL profile doesn't allow to clear SASL state.
> RFC 2222 (SASL), says:
> 
>     5.3.  Multiple authentications
> 
>        Unless otherwise stated by the protocol's profile, only one
>        successful SASL negotiation may occur in a protocol session.
>        In this case, once an authentication protocol exchange has
>        successfully completed, further attempts to initiate an
>        authentication protocol exchange fail.

Note again the statement above "Unless otherwise stated by the
protocol's profile". This proposed extension definitely affects a lot of
things. One of those areas it affects is the SASL profile for IMAP.

But that's okay; it just needs to be acknowledged within the proposed
extension that it extends the SASL profile for IMAP as well as the IMAP
protocol.

Lyndon Nerenberg wrote:

>    Tony> Lawrence's reply answers this objection sufficiently:
>    >> The SASL specification says that a layer ends when another
>    >> layer is turned on, ....
>
> No it doesn't. SASL may provide a mechanism, but 2060 doesn't. 2060
> would have to be changed to explicitly call out the behaviour during
> the state change. I.e., when exactly is integrety/protection turned
> off?
>
> Allowing an IMAP session to switch out of authenticated state
> (in any manner) seems to me to be a fundamental change to the
> semantics of the protocol. It's not extending the protocol, it's
> changing it. I don't think the IETF standards process allows us to
> do this.

Within the IMAP protocol, there already exists a transition out of
authenticated state (LOGOUT or drop connection). The proposed change to
the IMAP state machine is one additional transition from authenticated
or selected state to non-authenticated state. There are no new states.
IMNSHO, this is NOT a fundamental change.

Here's a revised state diagram showing the additional transition:

            +-------------------------------------------+
            |  initial connection and server greeting   |
            +-------------------------------------------+
                       || (1)           || (2)        || (3)
                       VV               ||            ||
            +-----------------------+   ||            ||
            |   non-authenticated   |   ||            ||
            +-----------------------+   ||            ||
             || (7) ^^ (8)    || (4)    ||            ||
             ||     ||        VV        VV            ||
             ||     ||   +----------------+           ||
             ||     ++<==| authenticated  |<=++       ||
             ||     ||   +----------------+  ||       ||
             ||     ||     || (7)   || (5)   || (6)   ||
             ||     ||     ||       VV       ||       ||
             ||     ||     ||    +--------+  ||       ||
             ||     ++=====||====|selected|==++       ||
             ||            ||    +--------+           ||
             ||            ||       || (7)            ||
             VV            VV       VV                VV
            +-------------------------------------------+
            |       logout and close connection         |
            +-------------------------------------------+

         (8) successful USERLOGOUT command

>    Tony> No, it's not something that most clients will utilize, nor
>    Tony> is it something that all servers need implement. But in
>    Tony> some contexts, such as the web-based email service mentioned
>    Tony> by Marko,
>
> The web server is just another IMAP client. It can, and should, cache
> IMAP connections just like any other IMAP client would.

Exactly. In one sense, web-based email servers are fundamentally
different from other IMAP clients. Because of the connectionless nature
of HTTP, they are servicing multiple users while trying to maintain the
fiction of a single maintained connection for each user. There are
several ways of doing this. Some of them cache the IMAP connections,
others don't. The ones that don't cache the connection aren't going to
be able to use this extension. But the ones that do can benefit, because
this extension now allows such caching to continue past the servicing of
a single user (serial mode), as well as allowing a single cached
connection to be used to service multiple users (bounce mode), neither
of which was not formerly possible.

	Tony Hansen
	[email-masked]

Date: Fri, 08 Oct 1999 08:27:01 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

"Larry Osterman (Platinum)" wrote:

> > No, there's no such assumption in this extension. The two concepts
> are
> > totally orthogonal. Each IMAP connection is a totally separate
> entity,
> > in and of itself, whether it maps into a thread on the server, or a
> > process, or whatever. Being able to manage those connections in a
> way
> > that lets the client reuse them is useful, for SOME CLIENTS.
> 
> Actually there is such an assumption - the stated purpose of this
> extension was to increase scalability in a n-tier environment.  See
> the abstract of the draft.  It clearly states that the design of the
> extension is driven by the high cost of connections:
> 
>    In such scenario, a component of a n-tier system may act as an
>    IMAP4 client on behalf of multiple end-users.  Present examples
>    of this include many WWW-based email services.  Initial profiling
>    suggests that persistent IMAP4 connections can lead to a
>    performance increase of an order of magnitude when compared to
>    separate IMAP4 connections per mailbox action.

If you add back the statement before this (deleted by Larry)

> The problem is that the perceived need for this facility in IMAP is
> based upon two assumptions:
>  1) The IMAP protocol requires one process per connection.

you'll see that Larry and I are arguing about two totally different
matters. I agree completely that the reason for the extension is "driven
by the high cost of connections". However, this has nothing to do,
necessarily, with processes, but is entirely about connections. As has
been pointed out, there are many architectures for IMAP servers and the
presumed assumption (1 process == 1 connection) is false. So holding
this assumption up as something to bash is a red herring.

> [N.B. ... lots of stuff leading up to this ...]
> Q:      But what if the client connection is NOT as long as the server
> connection?
> A:      Ahhh...  That must be it.  The server in question must in fact
> be an HTTP gateway backed by IMAP.  Since HTTP is a connectionless
> protocol, the server must be reestablishing the IMAP connection on
> EVERY incoming HTTP request.  In such an environment, the connection
> establishment time CAN start to overwhelm the operational cost, since
> you will be executing at most one authenticated IMAP verb for each
> HTTP request.
> 
> Why did I just waste all that time getting to this place?  To point
> out that there is only ONE case where this extension is of real
> benefit (which is confirmed by Tony and Marko's mail).  And that case
> is where you have an HTTP->IMAP proxy server that is written on HTTP
> 1.0.

Marko stated his reasons for this up front. Your list of logical steps
left off the possibilities of some alternatives at a few steps, but
definitely showed why this extension is needed for at least one
particular type of architecture.

> If it was written using HTTP 1.1, it would be possible to use
> fact that HTTP 1.1 is (sort-of) connection oriented to avoid
> continually reestablishing the connection with the IMAP server.
>
> My claim is that even if you use HTTP 1.0, you can put enough context
> in your URLs to allow you to use only one connection per HTTP CLIENT
> when talking to the server (as opposed to one connection per HTTP
> VERB).  You already have to cache the users  authorization credentials
> on the server (or you force the user to reauthenticate on every
> click), you can use this cache to hold your cached connection state.

This is an alternative architecture that leads to some other trade offs.
Yes, it may be viable in some places, but isn't always. 
Also, some scenarios appear even in architectures that do maintain
connections per CLIENT instead of per VERB, forcing them to start
reusing those connections for multiple client sessions.

> > No, it's not something that most clients will utilize, nor is it
> > something that all servers need implement. But in some
> > contexts, such as
> > the web-based email service mentioned by Marko,
> >
> >     o it is extremely useful in those contexts
> >
> >     o it's already been implemented differently in at least two
> > implementations
> >
> >     o it's worth standardizing on a single syntax
> >
> >     o (from the draft) "persistent IMAP4 connections can lead to a
> > performance increase of an order of magnitude when compared
> > to separate
> > IMAP4 connections per mailbox action"
> 
> If this is the case, then this should be submitted an experimental or
> informational extension and NOT standards track extension.  

Excellent idea. That would potentially avoid lots of hassle.

> You're going to have a REALLY hard time finding interoperable
> implementations if it's only implemented in your propriatary code
> bases.

That's just it; we'd love for it NOT be implemented in a proprietary
way. That way we could mix and match servers that implement it and have
a way of saying "if your server supported this feature, it would have a
higher chance of being in the running for us using it".

And I don't think there'd be a problem finding interoperable
implementations. We've already got two server developers that would like
to have a go at it.

	Tony Hansen
	[email-masked]

Date: Fri, 08 Oct 1999 09:00:48 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------B330542C269D9A376C4A5501
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> Mark Crispin wrote:
> >
> > I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
> > already defines an excellent multiplexing facility: TCP.  You are going to
> > encounter enormous opposition to duplicating TCP's work, especially in the
> > name of working around poorly-designed operating systems.
>
> Red herring. It's not reinventing multiplexing. It's introducing
> serialization at the application level within the context of an existing
> TCP connection. No duplication of TCP's work is happening.
>
> This is totally comparable to issuing another MAIL FROM to an SMTP
> connection after the first message's DATA block is sent. This feature is
> used by SMTP systems around the world today for the same reason: to
> avoid establishing a new socket between messages.
>

Precisely.

What most of the complainants seem to have missed is that setting up a secure
TCP link from (say) a web server to an IMAP server inside a firewall can be very
expensive.  Authentication negotiations and whatnot can easily dwarf the time
taken to login, check new mail and logout.  One should also bear in mind that
setting up the per-connection context for an IMAP connection varies from
ridiculously expensive to the relatively cheap.  (At either end of the spectrum,
it is possible for this IMAP set-up/tear-down to dominate a busy system.)

The arguments about SASL also also a red herring -- SASL is about authentication,
having established the users authenticity, the connection can be dropped back to
its pre-authenticated state with USERLOGOUT.  The security risks of doing so are
no greater than those imposed by dropping the connection and re-connecting (apart
from the time involved).

Of course, if one were to use TLS for authentication purposes, then one wouldn't
be able to use USERLOGOUT, but that is a completely different issue.
Non-authenticating TLS (and SSL which doesn't do authentication) is a different
matter of course.

jch

--------------B330542C269D9A376C4A5501
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------B330542C269D9A376C4A5501--

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: "Tony Hansen" <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Thu, 7 Oct 1999 15:02:10 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_30267_01BF10D4.F0B750C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments within, but warning - they are a bit long, but I think
relevant.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

>=20
> No, there's no such assumption in this extension. The two concepts are
> totally orthogonal. Each IMAP connection is a totally separate entity,
> in and of itself, whether it maps into a thread on the server, or a
> process, or whatever. Being able to manage those connections in a way
> that lets the client reuse them is useful, for SOME CLIENTS.

Actually there is such an assumption - the stated purpose of this
extension was to increase scalability in a n-tier environment.  See the
abstract of the draft.  It clearly states that the design of the
extension is driven by the high cost of connections:

   In such scenario, a component of a n-tier system may act as an IMAP4
   client on behalf of multiple end-users.  Present examples of this
   include many WWW-based email services.  Initial profiling suggests
   that persistent IMAP4 connections can lead to a performance increase
   of an order of magnitude when compared to separate IMAP4 connections
   per mailbox action.

> > 2) The costs of creating and destroying a process per=20
> connection are high.
> >
> > Assumption (2) also has clay feet; process=20
> creation/destruction is slow
> > because OS vendors have never felt the need to fix it.
>=20
> Bad assumption in the counter argument, as this may not have=20
> anything to
> do with creating and destroying a process per connection. If=20
> the server
> were implemented using threads, or some other paradigm that avoids
> process creation and destruction per connection, the fact remains that
> the very act of creating a socket connection is expensive on most
> current OS's. Maybe someday these limitations will also disappear, but
> that doesn't mean that the problem doesn't exist today and isn't worth
> providing for.

I guess I have a REALLY hard time believing that the cost of
creating/destroying a socket is significant relative to the cost of
actually performaing the relative IMAP operations.  And if it IS, I
further claim that the platform itself is broken and should be
considered as an inappropriate platform for a high performance server.
See my Socratic dialogue below.

> > (3) The servers that could benefit from this proposal would=20
> implement it.
>=20
> Sorry to disappoint you, Mark. You need to look at this from total
> system perspective. It's not the servers that would benefit from the
> proposal, but instead embedded systems acting as IMAP clients. These
> clients are using the IMAP servers in certain fashions of which you
> haven't yet considered all the ramifications. Marko's example of a web
> based email service is such an embedded system. I work with developers
> of similar systems as well, and this type of extension has=20
> already being
> implemented for them. The "combination of the client and server both
> supporting and using this extension" definitely can benefit from the
> extension, and have already done so.
>=20

I'm going to take issue with even this statement.  Lets work the logic
out step by step.

Q:	When does this proposal benefit a platform?
A:	When the cost of establishing/receiving a connection is a
significant percentage of the overall cost of the operation.  There are
no other cases where this is interesting.

Q:	When would the cost of RECEIVING a connection be a significant
percentage of the cost (ie. on the Server)?
A:	If the design of the server software is one-process-per-user, or
if the OS overhead of socket creation is too high.

Q:	Are there any solutions other than this extension that resolve
this?
A:	Yes.  As mentioned above, the IMAP server can be rewritten to
use a model other than one-process-per-user.

So if this extension is still needed, it is likely to be some
requirement of the CLIENT, not the server that is driving it (since the
server side can be fixed).

Q:	When would the cost of ESTABLISHING a connection be a
significant percentage of the cost (ie. on the Client)?
A:	When the client OS software makes it expensive - it might have
to dial a modem, etc.  But that begs the next question:

Q:	Would this extension help this case?
A:	No - what CLIENTS would be simultaneously supporting multiple
users?  Certainly not handheld devices or PCs.  The only case where a
CLIENT simultaneously supports multiple users is in the case of a proxy
client of one form or another.

So this extension is really targeted at improving the efficiency of
proxy servers (yes, I know this was a long road to go through to get
back to what Marko mentioned in his initial mail, but please bear with
me, I'm actually going somewhere with this).

Q:	So what is it about a proxy server that makes this extension
necessary?
A:	Nothing - proxy servers can establish a connection that lasts as
long as the client connection, so this isn't a big deal.

Q:	But what if the client connection is NOT as long as the server
connection?
A:	Ahhh...  That must be it.  The server in question must in fact
be an HTTP gateway backed by IMAP.  Since HTTP is a connectionless
protocol, the server must be reestablishing the IMAP connection on EVERY
incoming HTTP request.  In such an environment, the connection
establishment time CAN start to overwhelm the operational cost, since
you will be executing at most one authenticated IMAP verb for each HTTP
request.

Why did I just waste all that time getting to this place?  To point out
that there is only ONE case where this extension is of real benefit
(which is confirmed by Tony and Marko's mail).  And that case is where
you have an HTTP->IMAP proxy server that is written on HTTP 1.0.  If it
was written using HTTP 1.1, it would be possible to use fact that HTTP
1.1 is (sort-of) connection oriented to avoid continually reestablishing
the connection with the IMAP server.

My claim is that even if you use HTTP 1.0, you can put enough context in
your URLs to allow you to use only one connection per HTTP CLIENT when
talking to the server (as opposed to one connection per HTTP VERB).  You
already have to cache the users  authorization credentials on the server
(or you force the user to reauthenticate on every click), you can use
this cache to hold your cached connection state.

> No, it's not something that most clients will utilize, nor is it
> something that all servers need implement. But in some=20
> contexts, such as
> the web-based email service mentioned by Marko,
>=20
>     o	it is extremely useful in those contexts
>=20
>     o	it's already been implemented differently in at least two
> implementations
>=20
>     o	it's worth standardizing on a single syntax
>=20
>     o	(from the draft) "persistent IMAP4 connections can lead to a
> performance increase of an order of magnitude when compared=20
> to separate
> IMAP4 connections per mailbox action"

If this is the case, then this should be submitted an experimental or
informational extension and NOT standards track extension.  You're going
to have a REALLY hard time finding interoperable implementations if it's
only implemented in your propriatary code bases.

------=_NextPart_000_30267_01BF10D4.F0B750C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Comments within, but warning - they are a bit long, =
but I think relevant.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; No, there's no such assumption in this =
extension. The two concepts are</FONT>

<BR><FONT SIZE=3D2>&gt; totally orthogonal. Each IMAP connection is a =
totally separate entity,</FONT>

<BR><FONT SIZE=3D2>&gt; in and of itself, whether it maps into a thread =
on the server, or a</FONT>

<BR><FONT SIZE=3D2>&gt; process, or whatever. Being able to manage those =
connections in a way</FONT>

<BR><FONT SIZE=3D2>&gt; that lets the client reuse them is useful, for =
SOME CLIENTS.</FONT>
</P>

<P><FONT SIZE=3D2>Actually there is such an assumption - the stated =
purpose of this extension was to increase scalability in a n-tier =
environment.&nbsp; See the abstract of the draft.&nbsp; It clearly =
states that the design of the extension is driven by the high cost of =
connections:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; In such scenario, a component of a n-tier =
system may act as an IMAP4</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; client on behalf of multiple =
end-users.&nbsp; Present examples of this</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; include many WWW-based email =
services.&nbsp; Initial profiling suggests</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; that persistent IMAP4 connections can =
lead to a performance increase</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; of an order of magnitude when compared =
to separate IMAP4 connections</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; per mailbox action.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; 2) The costs of creating and destroying a =
process per </FONT>

<BR><FONT SIZE=3D2>&gt; connection are high.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Assumption (2) also has clay feet; process =
</FONT>

<BR><FONT SIZE=3D2>&gt; creation/destruction is slow</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; because OS vendors have never felt the need =
to fix it.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Bad assumption in the counter argument, as this =
may not have </FONT>

<BR><FONT SIZE=3D2>&gt; anything to</FONT>

<BR><FONT SIZE=3D2>&gt; do with creating and destroying a process per =
connection. If </FONT>

<BR><FONT SIZE=3D2>&gt; the server</FONT>

<BR><FONT SIZE=3D2>&gt; were implemented using threads, or some other =
paradigm that avoids</FONT>

<BR><FONT SIZE=3D2>&gt; process creation and destruction per connection, =
the fact remains that</FONT>

<BR><FONT SIZE=3D2>&gt; the very act of creating a socket connection is =
expensive on most</FONT>

<BR><FONT SIZE=3D2>&gt; current OS's. Maybe someday these limitations =
will also disappear, but</FONT>

<BR><FONT SIZE=3D2>&gt; that doesn't mean that the problem doesn't exist =
today and isn't worth</FONT>

<BR><FONT SIZE=3D2>&gt; providing for.</FONT>
</P>

<P><FONT SIZE=3D2>I guess I have a REALLY hard time believing that the =
cost of creating/destroying a socket is significant relative to the cost =
of actually performaing the relative IMAP operations.&nbsp; And if it =
IS, I further claim that the platform itself is broken and should be =
considered as an inappropriate platform for a high performance =
server.&nbsp; See my Socratic dialogue below.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; (3) The servers that could benefit from this =
proposal would </FONT>

<BR><FONT SIZE=3D2>&gt; implement it.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Sorry to disappoint you, Mark. You need to look =
at this from total</FONT>

<BR><FONT SIZE=3D2>&gt; system perspective. It's not the servers that =
would benefit from the</FONT>

<BR><FONT SIZE=3D2>&gt; proposal, but instead embedded systems acting as =
IMAP clients. These</FONT>

<BR><FONT SIZE=3D2>&gt; clients are using the IMAP servers in certain =
fashions of which you</FONT>

<BR><FONT SIZE=3D2>&gt; haven't yet considered all the ramifications. =
Marko's example of a web</FONT>

<BR><FONT SIZE=3D2>&gt; based email service is such an embedded system. =
I work with developers</FONT>

<BR><FONT SIZE=3D2>&gt; of similar systems as well, and this type of =
extension has </FONT>

<BR><FONT SIZE=3D2>&gt; already being</FONT>

<BR><FONT SIZE=3D2>&gt; implemented for them. The &quot;combination of =
the client and server both</FONT>

<BR><FONT SIZE=3D2>&gt; supporting and using this extension&quot; =
definitely can benefit from the</FONT>

<BR><FONT SIZE=3D2>&gt; extension, and have already done so.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I'm going to take issue with even this =
statement.&nbsp; Lets work the logic out step by step.</FONT>
</P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When does this =
proposal benefit a platform?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the cost of =
establishing/receiving a connection is a significant percentage of the =
overall cost of the operation.&nbsp; There are no other cases where this =
is interesting.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When would the cost =
of RECEIVING a connection be a significant percentage of the cost (ie. =
on the Server)?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the design of the =
server software is one-process-per-user, or if the OS overhead of socket =
creation is too high.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are there any =
solutions other than this extension that resolve this?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes.&nbsp; As =
mentioned above, the IMAP server can be rewritten to use a model other =
than one-process-per-user.</FONT>
</P>

<P><FONT SIZE=3D2>So if this extension is still needed, it is likely to =
be some requirement of the CLIENT, not the server that is driving it =
(since the server side can be fixed).</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When would the cost =
of ESTABLISHING a connection be a significant percentage of the cost =
(ie. on the Client)?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the client OS =
software makes it expensive - it might have to dial a modem, etc.&nbsp; =
But that begs the next question:</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Would this extension =
help this case?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No - what CLIENTS =
would be simultaneously supporting multiple users?&nbsp; Certainly not =
handheld devices or PCs.&nbsp; The only case where a CLIENT =
simultaneously supports multiple users is in the case of a proxy client =
of one form or another.</FONT></P>

<P><FONT SIZE=3D2>So this extension is really targeted at improving the =
efficiency of proxy servers (yes, I know this was a long road to go =
through to get back to what Marko mentioned in his initial mail, but =
please bear with me, I'm actually going somewhere with this).</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So what is it about a =
proxy server that makes this extension necessary?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nothing - proxy =
servers can establish a connection that lasts as long as the client =
connection, so this isn't a big deal.</FONT></P>

<P><FONT SIZE=3D2>Q:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; But what if the =
client connection is NOT as long as the server connection?</FONT>

<BR><FONT SIZE=3D2>A:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ahhh...&nbsp; That =
must be it.&nbsp; The server in question must in fact be an HTTP gateway =
backed by IMAP.&nbsp; Since HTTP is a connectionless protocol, the =
server must be reestablishing the IMAP connection on EVERY incoming HTTP =
request.&nbsp; In such an environment, the connection establishment time =
CAN start to overwhelm the operational cost, since you will be executing =
at most one authenticated IMAP verb for each HTTP request.</FONT></P>

<P><FONT SIZE=3D2>Why did I just waste all that time getting to this =
place?&nbsp; To point out that there is only ONE case where this =
extension is of real benefit (which is confirmed by Tony and Marko's =
mail).&nbsp; And that case is where you have an HTTP-&gt;IMAP proxy =
server that is written on HTTP 1.0.&nbsp; If it was written using HTTP =
1.1, it would be possible to use fact that HTTP 1.1 is (sort-of) =
connection oriented to avoid continually reestablishing the connection =
with the IMAP server.</FONT></P>

<P><FONT SIZE=3D2>My claim is that even if you use HTTP 1.0, you can put =
enough context in your URLs to allow you to use only one connection per =
HTTP CLIENT when talking to the server (as opposed to one connection per =
HTTP VERB).&nbsp; You already have to cache the users&nbsp; =
authorization credentials on the server (or you force the user to =
reauthenticate on every click), you can use this cache to hold your =
cached connection state.</FONT></P>

<P><FONT SIZE=3D2>&gt; No, it's not something that most clients will =
utilize, nor is it</FONT>

<BR><FONT SIZE=3D2>&gt; something that all servers need implement. But =
in some </FONT>

<BR><FONT SIZE=3D2>&gt; contexts, such as</FONT>

<BR><FONT SIZE=3D2>&gt; the web-based email service mentioned by =
Marko,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it is extremely useful =
in those contexts</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it's already been =
implemented differently in at least two</FONT>

<BR><FONT SIZE=3D2>&gt; implementations</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o it's worth =
standardizing on a single syntax</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; o (from the draft) =
&quot;persistent IMAP4 connections can lead to a</FONT>

<BR><FONT SIZE=3D2>&gt; performance increase of an order of magnitude =
when compared </FONT>

<BR><FONT SIZE=3D2>&gt; to separate</FONT>

<BR><FONT SIZE=3D2>&gt; IMAP4 connections per mailbox =
action&quot;</FONT>
</P>

<P><FONT SIZE=3D2>If this is the case, then this should be submitted an =
experimental or informational extension and NOT standards track =
extension.&nbsp; You're going to have a REALLY hard time finding =
interoperable implementations if it's only implemented in your =
propriatary code bases.</FONT></P>

</BODY>
</HTML>
------=_NextPart_000_30267_01BF10D4.F0B750C0--

Date: Thu, 07 Oct 1999 17:17:07 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Mark Crispin wrote:
> 
> I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
> already defines an excellent multiplexing facility: TCP.  You are going to
> encounter enormous opposition to duplicating TCP's work, especially in the
> name of working around poorly-designed operating systems.

Red herring. It's not reinventing multiplexing. It's introducing
serialization at the application level within the context of an existing
TCP connection. No duplication of TCP's work is happening.

This is totally comparable to issuing another MAIL FROM to an SMTP
connection after the first message's DATA block is sent. This feature is
used by SMTP systems around the world today for the same reason: to
avoid establishing a new socket between messages.

> As an ATT shareholder, I am very concerned about your report that ATT may be
> deploying "IMAP" software that only works with ATT software.  Can you assure
> us that ATT's "embedded systems" will interoperable with standard IMAP
> software?

As I said, it's a private extension. If the extension shows up in the
capabilities list, things work much faster. If the extension doesn't
show up in the capabilities list, you're back to the existing slow state
of dropping the connection and starting up a new connection.

	Tony Hansen
	[email-masked]

To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Date: Thu, 07 Oct 1999 15:06:24 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>>>>> "Tony" == Tony Hansen <[email-masked]> writes:

    Tony> Lyndon wrote:
    >> There's another problem with this. It's not going to work in
    >> the presence of SASL session integrity or protection. There's
    >> no provision in 2060 for turning either of these off once
    >> they've been established, and I don't see how an extension
    >> could change the base spec in a manner that allowed this
    >> without resetting the standards-track clock.

    Tony> Lawrence's reply answers this objection sufficiently:
    >> The SASL specification says that a layer ends when another
    >> layer is turned on, ....

No it doesn't. SASL may provide a mechanism, but 2060 doesn't. 2060
would have to be changed to explicitly call out the behaviour during
the state change. I.e., when exactly is integrety/protection turned
off?

Allowing an IMAP session to switch out of authenticated state
(in any manner) seems to me to be a fundamental change to the semantics
of the protocol. It's not extending the protocol, it's changing it.
I don't think the IETF standards process allows us to do this.

    Tony> No, it's not something that most clients will utilize, nor
    Tony> is it something that all servers need implement. But in some
    Tony> contexts, such as the web-based email service mentioned by
    Tony> Marko,

The web server is just another IMAP client. It can, and should, cache
IMAP connections just like any other IMAP client would.

--lyndon

Date: Thu, 7 Oct 1999 13:49:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-karppinen-imap-conman-00.txt
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Tony -

I'm sorry that you feel this way.  Nevertheless, the Internet protocol suite
already defines an excellent multiplexing facility: TCP.  You are going to
encounter enormous opposition to duplicating TCP's work, especially in the
name of working around poorly-designed operating systems.

As an ATT shareholder, I am very concerned about your report that ATT may be
deploying "IMAP" software that only works with ATT software.  Can you assure
us that ATT's "embedded systems" will interoperable with standard IMAP
software?

-- Mark --

Date: Thu, 07 Oct 1999 14:49:39 -0600
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Lyndon Nerenberg wrote:

> There's another problem with this. It's not going to work in
> the presence of SASL session integrity or protection. There's
> no provision in 2060 for turning either of these off once they've
> been established,

Exactly. Currently IMAP SASL profile doesn't allow to clear SASL state.
RFC 2222 (SASL), says:

    5.3.  Multiple authentications

       Unless otherwise stated by the protocol's profile, only one
       successful SASL negotiation may occur in a protocol session.  In
this
       case, once an authentication protocol exchange has successfully
       completed, further attempts to initiate an authentication
protocol
       exchange fail.

Alexey

Date: Thu, 07 Oct 1999 16:20:24 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Marko Karppinen wrote:
>
> I'm just writing to let you all know that a new extension to the
> IMAP4 protocol is being proposed in our new Internet-Draft,
> available from:
> http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt
> The basic idea is to allow multiple user sessions during a
> single socket connection to an IMAP4 server. The context
> in which this proved to be neccessary involves internal
> components of a web based email service. However special
> our application may seem, we at Icon Medialab and Chek believe
> that standardizing this sort of functionality before it gets
> implemented in various different ways is in everyone's interests.

In a similar context, we were forced to implement a private extension
almost exactly like USERLOGOUT and have found it EXTREMELY useful. We'd
love to switch to a standard name for the capability.

So far, the arguments I've seen against it seem somewhat specious.

Larry wrote:
> For example, there's no requirement that you run the
> IMAP server in a "one-process-per-connection" mode.
Mark wrote:
> The problem is that the perceived need for this facility in IMAP is based upon
> two assumptions:
>  1) The IMAP protocol requires one process per connection.

No, there's no such assumption in this extension. The two concepts are
totally orthogonal. Each IMAP connection is a totally separate entity,
in and of itself, whether it maps into a thread on the server, or a
process, or whatever. Being able to manage those connections in a way
that lets the client reuse them is useful, for SOME CLIENTS.

> 2) The costs of creating and destroying a process per connection are high.
>
> Assumption (2) also has clay feet; process creation/destruction is slow
> because OS vendors have never felt the need to fix it.

Bad assumption in the counter argument, as this may not have anything to
do with creating and destroying a process per connection. If the server
were implemented using threads, or some other paradigm that avoids
process creation and destruction per connection, the fact remains that
the very act of creating a socket connection is expensive on most
current OS's. Maybe someday these limitations will also disappear, but
that doesn't mean that the problem doesn't exist today and isn't worth
providing for.

> There's a third assumption, which is completely false and fatal to the
> proposal:
> (3) The servers that could benefit from this proposal would implement it.

Sorry to disappoint you, Mark. You need to look at this from total
system perspective. It's not the servers that would benefit from the
proposal, but instead embedded systems acting as IMAP clients. These
clients are using the IMAP servers in certain fashions of which you
haven't yet considered all the ramifications. Marko's example of a web
based email service is such an embedded system. I work with developers
of similar systems as well, and this type of extension has already being
implemented for them. The "combination of the client and server both
supporting and using this extension" definitely can benefit from the
extension, and have already done so.

Lyndon wrote:
> There's another problem with this. It's not going to work in
> the presence of SASL session integrity or protection. There's
> no provision in 2060 for turning either of these off once they've
> been established, and I don't see how an extension could change
> the base spec in a manner that allowed this without resetting the
> standards-track clock.

Lawrence's reply answers this objection sufficiently:
> The SASL specification says that a layer ends when another layer is
> turned on, ....

No, it's not something that most clients will utilize, nor is it
something that all servers need implement. But in some contexts, such as
the web-based email service mentioned by Marko,

    o	it is extremely useful in those contexts

    o	it's already been implemented differently in at least two
implementations

    o	it's worth standardizing on a single syntax

    o	(from the draft) "persistent IMAP4 connections can lead to a
performance increase of an order of magnitude when compared to separate
IMAP4 connections per mailbox action"

	Tony Hansen
	[email-masked]

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt 
Date: Thu, 7 Oct 1999 11:26:28 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2A01F_01BF10B6.CE534840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In general, "proxy" is virtually indistinguishable from "tunneling", and
it is almost always a bad idea.  The only place that I know of where
tunneling is reasonable is when passing through a firewall, otherwise
it's a nightmare.  And I know of NO situation where tunneling increases
scalability, because the throughput is almost always limited by the
throughput of the proxy server.

What is more interesting w.r.t. scalability is the Front-End/Back-End
scenario where the client talks to one of several front-end machines
each of which shares the same DNS A record (ie imap.myisp.net).  The
front-end machine then uses some protocol (possibly IMAP, possibly CIFS,
possibly NFS) to talk to the actual message store.  A solution of this
nature allows 2-way scalability without impacting the client - if you
overload your front-end machines, you can simply add more without
changing client configuration, similarly, if you find you are
overloading your back-end servers, you can again add more of them if
necessary.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lawrence Greenfield
> Sent: Thursday, October 07, 1999 11:11 AM
> To: [email-masked]; [email-masked]
> Subject: Re: draft-karppinen-imap-conman-00.txt=20
>=20
>=20
>    There's another problem with this. It's not going to work in
>    the presence of SASL session integrity or protection. There's
>    no provision in 2060 for turning either of these off once they've
>    been established, and I don't see how an extension could change
>    the base spec in a manner that allowed this without resetting the
>    standards-track clock.
>=20
> The SASL specification says that a layer ends when another layer is
> turned on, but that doesn't help with the other problems.
>=20
>    As Barry said, deficiencies in the implementation should be fixed
>    in the implementation. (I can say that, because we just=20
> went through
>    this specific exercise :-)=20
>=20
> I've considered adding a PROXY command so that a suitably privileged
> user can do something like:
>=20
> A001 PROXY leg LIST "" "*imap*"
>=20
> for some thoughts I've had about IMAP proxys to help with scalability,
> I've come to the conclusion that almost any of this is best done
> outside of the protocol.  The PROXY command would be a pain (without
> adding that much) to work with SELECT or any more complicated commands
> than LIST, etc.
>=20
> Larry
>=20

------=_NextPart_000_2A01F_01BF10B6.CE534840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>In general, &quot;proxy&quot; is virtually =
indistinguishable from &quot;tunneling&quot;, and it is almost always a =
bad idea.&nbsp; The only place that I know of where tunneling is =
reasonable is when passing through a firewall, otherwise it's a =
nightmare.&nbsp; And I know of NO situation where tunneling increases =
scalability, because the throughput is almost always limited by the =
throughput of the proxy server.</FONT></P>

<P><FONT SIZE=3D2>What is more interesting w.r.t. scalability is the =
Front-End/Back-End scenario where the client talks to one of several =
front-end machines each of which shares the same DNS A record (ie =
imap.myisp.net).&nbsp; The front-end machine then uses some protocol =
(possibly IMAP, possibly CIFS, possibly NFS) to talk to the actual =
message store.&nbsp; A solution of this nature allows 2-way scalability =
without impacting the client - if you overload your front-end machines, =
you can simply add more without changing client configuration, =
similarly, if you find you are overloading your back-end servers, you =
can again add more of them if necessary.</FONT></P>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-imapext@imc.=
org</A>]On</FONT>

<BR><FONT SIZE=3D2>&gt; Behalf Of Lawrence Greenfield</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, October 07, 1999 11:11 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-karppinen-imap-conman-00.txt =
</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; There's another problem with =
this. It's not going to work in</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the presence of SASL session =
integrity or protection. There's</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; no provision in 2060 for =
turning either of these off once they've</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; been established, and I don't =
see how an extension could change</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the base spec in a manner that =
allowed this without resetting the</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; standards-track clock.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The SASL specification says that a layer ends =
when another layer is</FONT>

<BR><FONT SIZE=3D2>&gt; turned on, but that doesn't help with the other =
problems.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; As Barry said, deficiencies in =
the implementation should be fixed</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; in the implementation. (I can =
say that, because we just </FONT>

<BR><FONT SIZE=3D2>&gt; went through</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; this specific exercise :-) =
</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I've considered adding a PROXY command so that a =
suitably privileged</FONT>

<BR><FONT SIZE=3D2>&gt; user can do something like:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; A001 PROXY leg LIST &quot;&quot; =
&quot;*imap*&quot;</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; for some thoughts I've had about IMAP proxys to =
help with scalability,</FONT>

<BR><FONT SIZE=3D2>&gt; I've come to the conclusion that almost any of =
this is best done</FONT>

<BR><FONT SIZE=3D2>&gt; outside of the protocol.&nbsp; The PROXY command =
would be a pain (without</FONT>

<BR><FONT SIZE=3D2>&gt; adding that much) to work with SELECT or any =
more complicated commands</FONT>

<BR><FONT SIZE=3D2>&gt; than LIST, etc.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Larry</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_2A01F_01BF10B6.CE534840--

Date: Thu, 7 Oct 1999 10:08:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
To: [email-masked]
cc: [email-masked]
Sender: [email-masked]

Unfortunately, I have to concur with Larry and Lyndon.

Internet history is littered with ideas that were technically excellent and
would have provided a useful facility, but were nonetheless unsuccessful.  I'm
afraid this is one of them.  This is not the first time this idea has been
proposed for IMAP, but the same reluctant conclusion resulted.

The problem is that the perceived need for this facility in IMAP is based upon
two assumptions:
 1) The IMAP protocol requires one process per connection.
 2) The costs of creating and destroying a process per connection are high.

If either assumption is false, the need collapses.  Examples can be found that
demonstrate either (or both) assumption(s), but that does not mean that the
assumptions are valid in all cases.

As Larry and Lydon have pointed out, assumption (1) is particularly weak.

Assumption (2) also has clay feet; process creation/destruction is slow
because OS vendors have never felt the need to fix it.  I can guarantee that
if a multi-billion dollar contract for Microsoft depended upon fast process
management, the next version of NT would be blindingly fast.  ;-)  Another way
around this would be if the operating system allowed process recycling; that
is, instead of the process being destroyed upon log out, that it be permitted
to place itself into a "standby" state.  In "standby", it regains root and is
suspended at its start address.  [Leaving aside the small matter of
programming here...but implementing conman would also require programming, and
in every client and server for every affected protocol.]

There's a third assumption, which is completely false and fatal to the
proposal:
 (3) The servers that could benefit from this proposal would implement it.

Unfortunately, this won't happen.  In the case of my server, it won't happen.
The entire security model of my server depends upon one process per
connection; servers setuid() themselves to the target user to discard their
root privileges irrecoverably, and all access control is done by file system
protections.

In order to implement conman, I would have to create an entirely different
security model.  But if I did that, there would be no reason to maintain the
current "one process per connection" other than laziness.  If I am lazy, I
wouldn't implement conman; if I am not lazy, I'd use a architecture such as
threading and conman would be unnecessary.

In conclusion, conman is unnecesary in those servers in which it would be
relatively easy to implement it; in the servers which conman would benefit, it
is incredibly difficult to implement and it would be easier to solve the
problem with a different server architecture.  Plus, a different server
architecture would not require any client changes.

Date: 7 Oct 1999 14:11:17 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Sender: [email-masked]

   There's another problem with this. It's not going to work in
   the presence of SASL session integrity or protection. There's
   no provision in 2060 for turning either of these off once they've
   been established, and I don't see how an extension could change
   the base spec in a manner that allowed this without resetting the
   standards-track clock.

The SASL specification says that a layer ends when another layer is
turned on, but that doesn't help with the other problems.

   As Barry said, deficiencies in the implementation should be fixed
   in the implementation. (I can say that, because we just went through
   this specific exercise :-) 

I've considered adding a PROXY command so that a suitably privileged
user can do something like:

A001 PROXY leg LIST "" "*imap*"

for some thoughts I've had about IMAP proxys to help with scalability,
I've come to the conclusion that almost any of this is best done
outside of the protocol.  The PROXY command would be a pain (without
adding that much) to work with SELECT or any more complicated commands
than LIST, etc.

Larry

To: [email-masked], [email-masked]
Subject: Re: draft-karppinen-imap-conman-00.txt 
Date: Thu, 07 Oct 1999 11:21:09 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

There's another problem with this. It's not going to work in
the presence of SASL session integrity or protection. There's
no provision in 2060 for turning either of these off once they've
been established, and I don't see how an extension could change
the base spec in a manner that allowed this without resetting the
standards-track clock.

As Barry said, deficiencies in the implementation should be fixed
in the implementation. (I can say that, because we just went through
this specific exercise :-) 

--lyndon

content-class: urn:content-classes:message
From: "Larry Osterman \(Platinum\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: draft-karppinen-imap-conman-00.txt
Date: Thu, 7 Oct 1999 10:04:57 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_27A1E_01BF10AB.6E0F9430
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I might humbly suggest that there are easier ways of acheiving your
desired goals than extending the protocol.  For example, there's no
requirement that you run the IMAP server in a
"one-process-per-connection" mode.  This DOES simplify some aspects of
the IMAP logic, but (as you have noted) the costs of creating and
destroying a process per connection can be overwhelming.

There are alternative models for the networking logic that do not
require one process per connection, for example, you could use a thread
per connection, or (if your platform supports it) use an asynchronous
I/O which allows a few threads to process all the I/O for your client.
I would strongly encourage you to investigate these possibilities,
otherwise I suspect that you will discover that you STILL have
performance issues, all this change does is to move the choke-point
location.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marko Karppinen
> Sent: Thursday, October 07, 1999 8:25 AM
> To: [email-masked]
> Subject: draft-karppinen-imap-conman-00.txt
>=20
>=20
> Hi,
>=20
> I'm just writing to let you all know that a new extension to the
> IMAP4 protocol is being proposed in our new Internet-Draft,
> available from:
>=20
> http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt
>=20
> The basic idea is to allow multiple user sessions during a
> single socket connection to an IMAP4 server. The context
> in which this proved to be neccessary involves internal
> components of a web based email service. However special
> our application may seem, we at Icon Medialab and Chek believe
> that standardizing this sort of functionality before it gets
> implemented in various different ways is in everyone's interests.
>=20
> We hope our Internet-Draft is a good starting point in discussing
> the need and possible implementations for this new functionality.
>=20
> Best regards,
>=20
> Marko Karppinen
> Icon Medialab
>=20
> On behalf of the authors
>=20
> --
> "Difficult to see, it is... always in motion is the future."
>=20

------=_NextPart_000_27A1E_01BF10AB.6E0F9430
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4113.0">
<TITLE>RE: draft-karppinen-imap-conman-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I might humbly suggest that there are easier ways of =
acheiving your desired goals than extending the protocol.&nbsp; For =
example, there's no requirement that you run the IMAP server in a =
&quot;one-process-per-connection&quot; mode.&nbsp; This DOES simplify =
some aspects of the IMAP logic, but (as you have noted) the costs of =
creating and destroying a process per connection can be =
overwhelming.</FONT></P>

<P><FONT SIZE=3D2>There are alternative models for the networking logic =
that do not require one process per connection, for example, you could =
use a thread per connection, or (if your platform supports it) use an =
asynchronous I/O which allows a few threads to process all the I/O for =
your client.&nbsp; I would strongly encourage you to investigate these =
possibilities, otherwise I suspect that you will discover that you STILL =
have performance issues, all this change does is to move the choke-point =
location.</FONT></P>

<P><FONT SIZE=3D2>Larry Osterman</FONT>

<BR><FONT SIZE=3D2>Sent from larryo-laptop.dns.microsoft.com running NT5 =
and Outlook 2000</FONT>

<BR><FONT SIZE=3D2>and Exchange Server 5.5.&nbsp; Please notify the =
sender of any difficulties</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-imapext@imc.=
org</A>]On</FONT>

<BR><FONT SIZE=3D2>&gt; Behalf Of Marko Karppinen</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, October 07, 1999 8:25 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: =
draft-karppinen-imap-conman-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Hi,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I'm just writing to let you all know that a new =
extension to the</FONT>

<BR><FONT SIZE=3D2>&gt; IMAP4 protocol is being proposed in our new =
Internet-Draft,</FONT>

<BR><FONT SIZE=3D2>&gt; available from:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-0=
0.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-karppinen-ima=
p-conman-00.txt</A></FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The basic idea is to allow multiple user =
sessions during a</FONT>

<BR><FONT SIZE=3D2>&gt; single socket connection to an IMAP4 server. The =
context</FONT>

<BR><FONT SIZE=3D2>&gt; in which this proved to be neccessary involves =
internal</FONT>

<BR><FONT SIZE=3D2>&gt; components of a web based email service. However =
special</FONT>

<BR><FONT SIZE=3D2>&gt; our application may seem, we at Icon Medialab =
and Chek believe</FONT>

<BR><FONT SIZE=3D2>&gt; that standardizing this sort of functionality =
before it gets</FONT>

<BR><FONT SIZE=3D2>&gt; implemented in various different ways is in =
everyone's interests.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; We hope our Internet-Draft is a good starting =
point in discussing</FONT>

<BR><FONT SIZE=3D2>&gt; the need and possible implementations for this =
new functionality.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Best regards,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Marko Karppinen</FONT>

<BR><FONT SIZE=3D2>&gt; Icon Medialab</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On behalf of the authors</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; --</FONT>

<BR><FONT SIZE=3D2>&gt; &quot;Difficult to see, it is... always in =
motion is the future.&quot;</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_27A1E_01BF10AB.6E0F9430--

Date: Thu, 07 Oct 1999 18:24:47 +0300
From: Marko Karppinen <[email-masked]>
Reply-To: [email-masked]
Organization: Icon Medialab
To: [email-masked]
Subject: draft-karppinen-imap-conman-00.txt
Sender: [email-masked]

Hi,

I'm just writing to let you all know that a new extension to the
IMAP4 protocol is being proposed in our new Internet-Draft,
available from:

http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt

The basic idea is to allow multiple user sessions during a
single socket connection to an IMAP4 server. The context
in which this proved to be neccessary involves internal
components of a web based email service. However special
our application may seem, we at Icon Medialab and Chek believe
that standardizing this sort of functionality before it gets
implemented in various different ways is in everyone's interests.

We hope our Internet-Draft is a good starting point in discussing
the need and possible implementations for this new functionality.

Best regards,

Marko Karppinen
Icon Medialab

On behalf of the authors

--
"Difficult to see, it is... always in motion is the future."

Date: Mon, 04 Oct 1999 18:23:59 -0600
From: Alexey Melnikov <[email-masked]>
To: Mike Gahrns <[email-masked]>
CC: [email-masked]
Subject: Re: Prohibitting enumaration of languages when specifying an extension
Sender: [email-masked]

Mike Gahrns wrote:

> *** Within
>
> > > >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> > > >       ; A client should not issue the optional extension parameter
> > > >       ; unless a server has indicated in its capabilities that it
> > > >       ; supports that extension
> > > >
> > > > I can't imagine any case when you want to use LANGUAGE command without
> > > specifying
> > > > language_tag. If somebody really wants this capability, I suggest to
> > > create new
> > > > command. So, my proposition is
> > > >
> > > > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> > > *** In earlier discussions, it was thought that being able to enumerate
> the
> > > languages available on the server would be helpful.  I agree, if at only
> for
> > > diagnosis purposes.
> >
> > I meant other case: Does something like "LANGUAGE (extension1 data1)"
> > make sense? What is the semantics of this command.
> *** I am not sure how this would be used, but thought that we shouldn't
> artificially limit this in case some extension wanted it.  e.g.   Give me
> the LIST of server languages that are supported by server, and then pass in
> the FOO extension parameter.  Perhaps the FOO extension without any tags
> would mean list in a response the languages you support for the FOO
> extension....

This make sense.

Alexey

From: "Mike Gahrns" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Subject: Prohibitting enumaration of languages when specifying an extension
Date: Mon, 4 Oct 1999 12:05:08 -0700
Sender: [email-masked]

*** Within

> > >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> > >       ; A client should not issue the optional extension parameter
> > >       ; unless a server has indicated in its capabilities that it
> > >       ; supports that extension
> > >
> > > I can't imagine any case when you want to use LANGUAGE command without
> > specifying
> > > language_tag. If somebody really wants this capability, I suggest to
> > create new
> > > command. So, my proposition is
> > >
> > > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> > *** In earlier discussions, it was thought that being able to enumerate
the
> > languages available on the server would be helpful.  I agree, if at only
for
> > diagnosis purposes.
>
> I meant other case: Does something like "LANGUAGE (extension1 data1)"
> make sense? What is the semantics of this command.
*** I am not sure how this would be used, but thought that we shouldn't
artificially limit this in case some extension wanted it.  e.g.   Give me
the LIST of server languages that are supported by server, and then pass in
the FOO extension parameter.  Perhaps the FOO extension without any tags
would mean list in a response the languages you support for the FOO
extension....

Date: Mon, 4 Oct 1999 11:25:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
To: Alexey Melnikov <[email-masked]>
cc: Mike Gahrns <[email-masked]>, [email-masked]
Sender: [email-masked]

Although I understand the motivation for the TRANSLATION extension to
NAMESPACE, I feel that there is a major problem with it.

The example shows a namespace called "Other Users/" with a translation of
"Autres Utilisateurs/".  Leaving aside the bogosity of the missing "#"
(particularly in light of the personal namespace), this example is going to
give certain individuals a strong feeling that "Autres Utilisateurs/" is a
valid namespace name.  This, in turn, implies that it is valid to use it in
URLs.

I strongly oppose localization of strings that could appear in a mailbox name
and/or a URL.  It's enough of a problem that they can be internationalized.

I suggest instead that we add a field in namespace called COMMENT or
DESCRIPTION, and that this new field can be localized.  This opens the
possibility for this field to be English; #public/ and #shared/ are very two
different things in my server, but that fact is not obvious from those names.

Since this no longer changes the namespace names, the draft can be simplied
and the troublesome rules between LANGUAGE and NAMESPACE can be deleted.

This has another desirable effect.  It may break client implementors of the
deplorable habit of treating the NAMESPACE command as simply another level of
hierarchy to a common root.  I've learned not to underestimate the grim
determination of certain client vendors to do the wrong thing in the face of
intense pressure from the specification otherwise. ;-)  But, maybe by having
the localized string as a comment, it may tip the balance towards treating
namespaces as independent hierarchies.

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Oct 1999 11:21:12 -0600
To: Mike Gahrns <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 4 Oct 1999 08:07:44 -0700 Mike Gahrns <[email-masked]> 
wrote:

> Hi Alexey,
> 
> *** Comments within.
> 
> P.S.  I will have very limited access to e-mail the next 2.5 weeks, so I
> will be slow in responding to any comments.
> 
> 
> 
> > Hi Mike,
> >
> > Here is some comments about the last draft:
> >
> >    1). If server supports both LANGUAGE and NAMESPACE it MUST return
> NAMESPACE
> > response:
> > I would rather replace MUST with SHOULD, because when you describe
> TRANSLATION, you
> > says that
> > TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't
> be sent and
> > NAMESPACE hasn't been changed - why send NAMESPACE response at all?
> *** To make it a MUST was a request I receivedd on the previous draft.  The
> rational was that it made it slightly easier for clients if they knew to
> always expect a NAMESPACE response (if the server supports NAMESPACE).  I
> don't have strong feelings here, either way, but tend to agree that always
> sending the response could make things simpler.
>

I don't mind, but draft should state that explicitely.
Without this comment "MUST" doesn't make sense.
  
> >    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
> >       ; A client should not issue the optional extension parameter
> >       ; unless a server has indicated in its capabilities that it
> >       ; supports that extension
> >
> > I can't imagine any case when you want to use LANGUAGE command without
> specifying
> > language_tag. If somebody really wants this capability, I suggest to
> create new
> > command. So, my proposition is
> >
> > LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
> *** In earlier discussions, it was thought that being able to enumerate the
> languages available on the server would be helpful.  I agree, if at only for
> diagnosis purposes.

I meant other case: Does something like "LANGUAGE (extension1 data1)" 
make sense? What is the semantics of this command.

> >    4). Primary language: Accordingly to Alvestrand RFC language tag is not
> always
> > hierarchical. This means that you can't always assume that x-y-z is
> sublanguage of x-y.
> > This means that server should have some additional knowledge about
> languages it
> > supports.
> *** Can you suggest some text to address this?

Yes, I will.
---------------
Alexey Melnikov
Software Developer    phone: (780) 424 4922 x 357
MessagingDirect Ltd.  fax  : (780) 424 4925

mailto:[email-masked]
http://www.MessagingDirect.com

* This e-mail message was sent with Execmail V5.0 *

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-gahrns-imap-language-01
Date: Mon, 4 Oct 1999 08:07:44 -0700
Sender: [email-masked]

Hi Alexey,

*** Comments within.

P.S.  I will have very limited access to e-mail the next 2.5 weeks, so I
will be slow in responding to any comments.

> Hi Mike,
>
> Here is some comments about the last draft:
>
>    1). If server supports both LANGUAGE and NAMESPACE it MUST return
NAMESPACE
> response:
> I would rather replace MUST with SHOULD, because when you describe
TRANSLATION, you
> says that
> TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't
be sent and
> NAMESPACE hasn't been changed - why send NAMESPACE response at all?
*** To make it a MUST was a request I receivedd on the previous draft.  The
rational was that it made it slightly easier for clients if they knew to
always expect a NAMESPACE response (if the server supports NAMESPACE).  I
don't have strong feelings here, either way, but tend to agree that always
sending the response could make things simpler.

>
>    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
>       ; A client should not issue the optional extension parameter
>       ; unless a server has indicated in its capabilities that it
>       ; supports that extension
>
> I can't imagine any case when you want to use LANGUAGE command without
specifying
> language_tag. If somebody really wants this capability, I suggest to
create new
> command. So, my proposition is
>
> LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
*** In earlier discussions, it was thought that being able to enumerate the
languages available on the server would be helpful.  I agree, if at only for
diagnosis purposes.

>
>    3). EXTENSION = SP "(" string SP "(" string *(SP string)")" ")"
>
> I suspect that first parameter in the list is LANGUAGE extension name. I
prefer to
> mention that.
**** this is correct and I good suggestion I will incorporate into a future
revision

>
>    4). Primary language: Accordingly to Alvestrand RFC language tag is not
always
> hierarchical. This means that you can't always assume that x-y-z is
sublanguage of x-y.
> This means that server should have some additional knowledge about
languages it
> supports.
*** Can you suggest some text to address this?

>
>    5). Does TRANSLATION NAMESPACE extension eliminates the need to change
namespace
> prefixes?
*** Yes, that is the idea.  (this would allow for things like preserving
urls across messages, and leave it up to the client to translate namespaces
if necessary)

> I would suggest adding something like "SHOULD NOT change namespace prefix"
*** I can add this.

>
>
> Alexey
>

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-gahrns-imap-language-01.txt
Date: Mon, 04 Oct 1999 07:08:15 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 Language Extension
	Author(s)	: M. Gahrns
	Filename	: draft-gahrns-imap-language-01.txt
	Pages		: 8
	Date		: 01-Oct-99
	
The Internet Message Access Protocol [RFC-2060] allows server 
responses to include human-readable text that in many cases needs to 
be presented to the user.  This document specifies a way for a 
client to negotiate which language the server should use when 
sending human-readable text.  It provides an extensible mechanism so 
that it may be used as a framework for full internationalization of 
other IMAP extensions such as SORT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gahrns-imap-language-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-language-01.txt

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

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

--OtherAccess--

--NextPart--