Subject: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 24 Sep 2007 13:35:55 +0200

[email-masked] writes:
> A new Request for Comments is now available in online RFC libraries.
>
>         RFC 4959

Lemonade blocks on this, right? Well, it's published.

Arnt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Mon, 24 Sep 2007 08:33:04 -0700 (PDT)

> Lemonade blocks on this, right? Well, it's published.

Why on earth would Lemonade block on this?

Sheesh.  There's a difference between must-have and nice-to-have.  SASL-IR 
is, at best, nice-to-have.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 24 Sep 2007 16:44:27 +0100

On Mon Sep 24 16:33:04 2007, Mark Crispin wrote:
> Sheesh.  There's a difference between must-have and nice-to-have.   
> SASL-IR is, at best, nice-to-have.

"Blocks" is also relative. It is a normatively required reference.  
But we could have ditched it if it looked like it would have  
seriously delayed us.

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 24 Sep 2007 08:49:24 -0700 (PDT)

On Mon, 24 Sep 2007, Dave Cridland wrote:
> "Blocks" is also relative. It is a normatively required reference. But we 
> could have ditched it if it looked like it would have seriously delayed us.

How is it normatively required?

At most, it should be a recommendation to save an RTT.  But there are many 
other RTT savings that are far more critical than this one.

-- Mark --

http://panda.com/mrc

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Sep 2007 10:19:41 +0100

> How is it normatively required?
It's a MUST for servers to implement in Profile Bis. There are no  
SHOULDs in Profile Bis for servers.

Clients don't have to - I think, without looking, that it's a SHOULD,  
like many of these things, although given that the only case where  
it's useful is with PLAIN (and we have LOGIN which does the same  
thing for the common case), EXTERNAL (a nice idea, but unlikely to  
occur in the real world), and DIGEST-MD5 (moving to Historic), then  
few clients are likely to use it in practise. But should a new  
mechanism arise that's useful here (YAP-* springs to mind), then it's  
there, deployed and ready.

It's also not terribly hard to implement, so it's not a burden - in  
my opinion, having implemented it in client and server.

> At most, it should be a recommendation to save an RTT.  But there  
> are many other RTT savings that are far more critical than this one.

Sure. It's a single round-trip at session-startup. Savings of  
round-trips for the more repetitive actions (such as SELECT time, or  
FETCHes) are way more important, of course.

So I'm agreeing with you in entirety - it's a nice-to-have, and we  
can have it without delay, so we'll have it. If it were likely to  
delay Profile Bis, it should have been dropped.

Whether Profile Bis ought to have SHOULDs for servers is a whole  
debate in and of itself.

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 15:46:56 +0200

> Why on earth would Lemonade block on this?

There was talk of that happening a few months ago. At the December 
interim? Prague meeting? Sometime around then. Someone said something 
like "the document is done already and widely implemented, so it's a 
one-RTT improvement at practically no cost". If. I. Remember. 
Correctly. I didn't care much at the time, since there was nothing for 
me to do in either case.

> SASL-IR is, at best, nice-to-have.

I rather agreed with that when I read the -00 draft. But since so many 
widely used servers have implemented the extension I think a published 
specification is now more than just "nice to have".

(I wish I knew why so many people implemented this particular extension.)

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 08:26:39 -0700 (PDT)

On Tue, 25 Sep 2007, Dave Cridland wrote:
> It's a MUST for servers to implement in Profile Bis. There are no SHOULDs in 
> Profile Bis for servers.

This is a mistake.  It should be removed.  Lemonade does NOT need this.

On the other hand, Lemonade is rapidly moving to irrelevance.  So it may 
not matter.

> It's also not terribly hard to implement, so it's not a burden - in my 
> opinion, having implemented it in client and server.

It all depends.  It is arguably a layering violation; the obvious way to 
implement it is to hold it in a buffer until the SASL layer is started. 
But I agree that there are more horrible things in the world.

> So I'm agreeing with you in entirety - it's a nice-to-have, and we can have 
> it without delay, so we'll have it. If it were likely to delay Profile Bis, 
> it should have been dropped.

It should be dropped because it is unnecessary and adds complexity to 
something that is already unnecessarily complex.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 08:29:39 -0700 (PDT)

> (I wish I knew why so many people implemented this particular extension.)

It's low-hanging fruit for open source servers.  However, don't delude 
yourself; as it is not necessary (other than this silly statement by 
Lemonade), it won't be implemented by a server which is trying to minimize 
its bloat by NOT implementing unnecessary extensions.  I know of servers 
which are in that situation.

-- Mark --

http://panda.com/mrc

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Sep 2007 17:24:12 +0100

> This is a mistake.  It should be removed.  Lemonade does NOT need  
*sigh* Can you make a compelling argument why it should be removed?

> On the other hand, Lemonade is rapidly moving to irrelevance.  So  
> it may not matter.
> 
> 
This really doesn't match what I'm seeing, both in my professional  
and personal capacities. For a start, I'm seeing clients being  
developed for consumer-grade devices which use Lemonade. Whether  
they're actually advertising the fact in their glossy manuals is  
another matter.

I'm really not sure why you're arguing so heavily against something  
so simple, especially if you've apparently decided it's all  
irrelevant anyway.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Sep 2007 17:33:57 +0100

Dave Cridland wrote:

>> On the other hand, Lemonade is rapidly moving to irrelevance.  So  it 
>> may not matter.
>

I also don't understand why you are arguing against inclusion of 
something you've implemented into something you have no plans to implement.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 09:38:33 -0700 (PDT)

> *sigh* Can you make a compelling argument why it should be removed?

It is a basic principle that any requirement that is not needed should be 
removed.

> I'm really not sure why you're arguing so heavily against something so 
> simple, especially if you've apparently decided it's all irrelevant anyway.

I don't want to be blamed when Lemonade turns out to be a miserable 
failure.  I don't see the mobile device world moving towards Lemonade; 
just see lots of talk, reminiscent of the OSI fiasco in the 1980s.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 09:41:14 -0700 (PDT)

On Tue, 25 Sep 2007, Alexey Melnikov wrote:
> I also don't understand why you are arguing against inclusion of something 
> you've implemented into something you have no plans to implement.

It is the difference between fluff in an open-source server 
implementation, and fluff in a mandatory-to-implement function set.

Is Lemonade serious about having a viable solution to non-IETF (and 
generally proprietary) standards for mobile device email?  Or do you want 
to repeat the OSI fiasco of the 1980s?

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 22:56:52 +0200

Mark Crispin writes:
> It's low-hanging fruit for open source servers.

Hm... the document shepherd asked me whether I had a list of 
implementations, so I wrote to various maintainers asking whether 
they'd implemented it. Two authors of closed-source servers responded 
to the question by implementing it. That shocked me.

> However, don't delude yourself; as it is not necessary (other than 
> this silly statement by Lemonade), it won't be implemented by a 
> server which is trying to minimize its bloat by NOT implementing 
> unnecessary extensions.  I know of servers which are in that 
> situation.

I don't disagree with that.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 14:06:05 -0700 (Pacific Daylight Time)

On Tue, 25 Sep 2007, Arnt Gulbrandsen wrote:
> Hm... the document shepherd asked me whether I had a list of implementations, 
> so I wrote to various maintainers asking whether they'd implemented it. Two 
> authors of closed-source servers responded to the question by implementing 
> it. That shocked me.

I'm thinking of one major closed-source server which doesn't.

On the other hand, that server's vendor is aggressively working to kill 
IMAP by deprecating it as being "legacy" and "obsolete", so I doubt it 
will ever support Lemonade.  That non-IMAP component of that server will 
do mobile devices via its proprietary protocol though.

>> However, don't delude yourself; as it is not necessary (other than this 
>> silly statement by Lemonade), it won't be implemented by a server which is 
>> trying to minimize its bloat by NOT implementing unnecessary extensions.  I 
>> know of servers which are in that situation.

Hence my argument that Lemonade should aggressively trim fat from all 
requirements.  The SASL-IR requirement is an example of such fat that 
should be trimmed.  Every little bit of fat hurts, not helps, the 
long-term chances of Lemonade's viability.

I personally fear that it is already too late (we missed our window), but 
that won't stop me from trying to see the right thing happen.

-- Mark --

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 23:36:02 +0200

Mark Crispin writes:
> requirements.

Amen to that. Can you suggest a list, e.g. "five biggest pieces of bloat"?

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Sep 2007 18:02:31 -0700 (Pacific Daylight Time)

> Amen to that. Can you suggest a list, e.g. "five biggest pieces of bloat"?

I haven't been paying close enough attention; just noting overall tone of 
the discussions.  SASL-IR was so obvious that it stood out.

I suggest that each and every requirement in the profile be subject to a 
"how bad would it be if this is omitted?" consideration, paying particular 
example to things that are currently optional today (and thus have a 
reasonable chance of being there even if not mandatory).  It isn't good 
enough to be "nice to have".  If it isn't critical, it should go.

For example, the trio stands out as being critical, as it is our solution 
to forward without download.  So the trio make the cut.

-- Mark --

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 26 Sep 2007 11:00:00 +0200

Mark Crispin writes:
> I suggest that each and every requirement in the profile be subject to 
> a "how bad would it be if this is omitted?" consideration, paying 
> particular example to things that are currently optional today (and 
> thus have a reasonable chance of being there even if not mandatory).  
> It isn't good enough to be "nice to have".  If it isn't critical, it 
> should go.

People have seemed to place great emphasis on saving roundtrips at 
startup, and SASL-IR saves one in the very common case of 
STARTTLS+PLAIN. If roundtrips are that important, I don't see how 
SASL-IR can be faulted.

> For example, the trio stands out as being critical, as it is our 
> solution to forward without download.  So the trio make the cut.

Strictly speaking it's two solutions, each of which requires three 
extensions. Servers must implement four extensions, clients can choose 
which three to use. Seems mildly bloated to me.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 26 Sep 2007 09:12:01 -0700 (PDT)

On Wed, 26 Sep 2007, Arnt Gulbrandsen wrote:
> People have seemed to place great emphasis on saving roundtrips at startup, 
> and SASL-IR saves one in the very common case of STARTTLS+PLAIN. If 
> roundtrips are that important, I don't see how SASL-IR can be faulted.

Does it require automatic capability announcement in the startup banner 
and in the authentication response?  That is far more important than 
SASL-IR, since that saves two RTTs every time.

Does it add a new, two-stage, STARTTLS that can announce automatic 
capabilities after TLS is in effect?  That saves another one, every time.

If not, it seems that Lemonade is failing to see the forest for the trees.

-- Mark --

http://panda.com/mrc

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Sep 2007 17:45:02 +0100

On Tue, 25 Sep 2007, Dave Cridland wrote:
>
> EXTERNAL (a nice idea, but unlikely to occur in the real world)

One of my friends set up the infrastructure in his company to do
single-sign-on with X.509.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.