Subject: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt

From: [email-masked]
Date: Fri, 20 Jun 2008 05:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF.

	Title           : The Lemonade Profile
	Author(s)       : D. Cridland, et al.
	Filename        : draft-ietf-lemonade-profile-bis-09.txt
	Pages           : 35
	Date            : 2008-06-20

This document describes a profile (a set of required extensions,
restrictions and usage modes) of the IMAP and mail submission
protocols.  This profile allows clients (especially those that are
constrained in memory, bandwidth, processing power, or other areas)
to efficiently use IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to
download and upload the mail, to optimize submission and to
efficiently resynchronize in case of loss of connectivity with the
server.
The Lemonade profile relies upon several extensions to IMAP and Mail
Submission protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 16:49:04 +0300

>    In addition to this list, any Lemonade Message Stores MUST send the
>    CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial
>    server greeting and after the LOGIN/AUTHENTICATE commands.

Since some older clients want to issue CAPABILITY command always and
just ignore the capabilities sent in greeting/LOGIN/AUTHENTICATE
replies, how about a small change to this:

"If a client issues a CAPABILITY command depite having already received
the capability in the greeting, the server MAY omit the CAPABILITY
response from the LOGIN/AUTHENTICATE commands."

Or something like that.

---

From: Mark Crispin <[email-masked]>
Date: Sat, 21 Jun 2008 07:22:12 -0700

> response from the LOGIN/AUTHENTICATE commands."

This is a very bad idea.  It makes assumptions about the client which are not necessarily the case.

_________________________________________________________________
The other season of giving begins 6/24/08. Check out the i’m Talkathon.
http://www.imtalkathon.com?source=TXT_EML_WLH_SeasonOfGiving
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 17:23:20 +0300

Also in sections 8.4.1 and 8.4.2:

> Mail submission server opens IMAP connection to the IMAP server:
> 
>          I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
>              CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
>              IMAP server ready
..
> Note that if the IMAP server doesn't send CAPABILITY response code in
>    the greeting, the mail submission server must issue the CAPABILITY
>    command to learn about supported IMAP extensions as described in
>    [IMAP].

Perhaps it should rather say "if IMAP server doesn't send CAPABILITY
response code in LOGIN/AUTHENTICATE command", since that's where servers
seem to send the URLAUTH capability.

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 17:25:46 +0300

> This is a very bad idea.  It makes assumptions about the client which are not necessarily the case.

Even if the client didn't ignore them, what's the point of sending the
same CAPABILITY reply to the client twice? (Assuming of course it
doesn't change. If it does change, then sure it should be sent.)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 21 Jun 2008 16:44:29 +0200

Timo Sirainen writes:
> replies, [,,,]

Pretty much all older clients need some sort of change to take advantage 
of the lemonade goodies. A bigger change than learning to parse the 
CAPABILITY response-code.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Sat, 21 Jun 2008 07:55:47 -0700

> doesn't change. If it does change, then sure it should be sent.)

Are you, personally, willing to guarantee that this proposed additional (and IMHO pointless) complexity will never cause a problem, now and in the future?

It IS additional complexity.  It is an added behavior rule, with implications for both server and client.  The sole apparent purpose is to save a few octets of network traffic.  The cost is that misbehavior by either client or server will cause bugs.

I don't know why I'm bothering.  Nobody pays me to work on IMAP any more (in fact, nobody is paying me at all).  I should just shut up and go away.  But this proposal was just so bad and so unnecessary that I felt that I had to say something.

---

From: [email-masked]
Date: Sat, 21 Jun 2008 14:56:53 +0000

Why make the server that much more complex and required to hold that much more state?
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Timo Sirainen <[email-masked]>

Date: Sat, 21 Jun 2008 17:25:46 
To:Mark Crispin <[email-masked]>
Cc:lemonade <[email-masked]>
Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 18:04:02 +0300

> CAPABILITY response-code.

That's kind of the point. To write a Lemonade-compliant IMAP server I'd
now have to send useless data to (a lot of) existing non-Lemonade
clients.

Another try at rewording what I meant:

"CAPABILITY response code MAY be omitted from LOGIN/AUTHENTICATE command
response if an equivalent CAPABILITY was already sent to the client, for
example due to a CAPABILITY command or if the full CAPABILITY was
already sent in the banner. STARTTLS however resets this capability
tracking. CAPABILITY replies are equivalent if after removing
capabilities that are relevant only in pre-authenticated state (e.g.
AUTH=*, STARTTLS) they have exactly the same capabilities left."

That brings to my mind though: Should CAPABILITY reponse code also be a
"MUST be sent" for STARTTLS reply? RFC 3501 already says the CAPABILITY
command SHOULD be reissued.

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 18:15:19 +0300

On Sat, 2008-06-21 at 07:55 -0700, Mark Crispin wrote:
> Are you, personally, willing to guarantee that this proposed
> additional (and IMHO pointless) complexity will never cause a problem,
> now and in the future?
> 
> It IS additional complexity.  It is an added behavior rule, with
> implications for both server and client.  The sole apparent purpose is
> to save a few octets of network traffic.  The cost is that misbehavior
> by either client or server will cause bugs.

Well, yes, it is extra complexity.. Maybe it could be said somehow in a
bit more simple way that would give the same result for Lemonade
clients. But I guess it doesn't really matter, since the environments
where those few extra bytes might matter should probably be using
Lemonade anyway.

But what about the STARTTLS reply having CAPABILITY?

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jun 2008 18:26:01 +0300

> But what about the STARTTLS reply having CAPABILITY?

I forgot that the tagged OK was sent before TLS negotiation was started,
not after. I guess that can't be helped either then, so just forget
about everything I said in this thread..

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jun 2008 20:37:08 +0100

On Sat Jun 21 15:55:47 2008, Mark Crispin wrote:
> additional (and IMHO pointless) complexity will never cause a  
> problem, now and in the future?
> 
> 
FWIW, I'm not willing to guarantee it, without investing quite a bit  
of work which, I'd point out, saves no round-trips, and only a small  
amount of bandwidth for sub-optimal clients at startup.

> implications for both server and client.  The sole apparent purpose  
> is to save a few octets of network traffic.  The cost is that  
> misbehavior by either client or server will cause bugs.
> 
> 
Agreed.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade