Subject: Re: [lemonade] On WGLC: profile-bis [was Re: Proposed Agenda for Dublin]

From: Dan Karp <[email-masked]>
Date: Thu, 24 Jul 2008 14:12:56 -0700 (PDT)

> Whilst it seems late to mention ManageSIEVE in profile-bis, it is in 
> the document that is in WGLC.  If there are substantive WGLC comments,
> please make them.

A few comments; you can decide if they qualify as "substantive":

 - profile-bis should go to press after all its dependencies are
published.  You can assume that ManageSIEVE will be acceptable in
its final form, but that's a non-negligible risk.

 - ManageSIEVE introduces a new server and protocol that's similar but
not identical to IMAP.  I understand that a separate ManageSIEVE server
is useful in the abstract case where you're not sure what other services
will be available on a server.  But in the Lemonade case, there *must*
be an IMAP server running -- is there no way to find a middle ground that
merges these IMAP-like SIEVE functions into the IMAP server?  Writing
Yet Another Slightly-Different Server is a pain in the kiester that I'd
prefer to avoid if at all possible.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 Jul 2008 17:52:35 -0700 (PDT)

> its final form, but that's a non-negligible risk.

FWIW, ManageSieve is about to go to IETF last call. I will also point out that
the design of ManageSieve is out of scope for Lemonade; this is properly the
purview of the Sieve WG.

> prefer to avoid if at all possible.

Sure, and while we're at it why not put in SMTP submit, and ACAP, and
maybe LDAP?

IMAP is already too complex and performs at least one function too many
(mailbox lists handling). If anything we should be looking for ways to simplify
it, not ways to cram more stuff into it, especially stuff that's largely
unrelated to its core mission of providing mail access.

The more stuff you cram into a single server, the more it constrains that
server to a particular style of operation that may not be appropriate for all
its functions. It also creates a single point of failure.

I also like the freedom of being able to put the ManageSieve server somewhere
other than the IMAP server. In particular, I want the freedom to colocate the
ManageSieve server where the sieves themselves are stored, which may or may not
be part of the Message Store.

Mind you, I think using the IMAP protocol style for something as simple as
ManageSieve is overkill. But IMO not abandoning the installed base trumps the
small gain we'd get by shifting to a simpler protocol style.

				Ned

P.S. My indifference to profiles in general extends to whether or not
ManageSieve is part of Lemonade profile-bis. However, this is morping into a
discussion of how Sieve management should be done, which does concern me.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Thu, 24 Jul 2008 19:10:21 -0700

This may get me banned, but I have to say it.

> Sure, and while we're at it why not put in SMTP submit, and ACAP, and

If you are really going to put orthogonal functionality into IMAP, what IMAP needs is calendaring, contacts management, and task list management.  That is the standard set by Exchange; and yes, boys and girls, Exchange is the standard.

Of course, given the proven utter incompetence of the IETF to build decent protocols to accomplish calendaring, contacts management, and task list management, such an undertaking would have failed even more spectacularly than the Lemonade effort is failing.

> unrelated to its core mission of providing mail access.

I'm glad to see that someone else has come around to saying what I've been saying for the past 22 years.

> its functions. It also creates a single point of failure.

As the kids say, "well duh!"

My jaw drops at the ridiculous number of IMAP extensions that Lemonade has created.  Everybody and their grandmother has their own favorite little tweak, and all these tweaks went in because there is no responsible adult to say "no".  It's just like all the crap that was added into TELNET and FTP; and not just the old crap but also the new crap after the advent of SSH.

Now there is this ridiculous "Profile" that supposedly people will pay attention to.  Microsoft won't do any of this crap.  Nor will Google.  Nor will Apple.

This working group should have disbanded immediately after creating the trio.  The odds were always slender, but at least there was a chance.  Notifications should have been punted to another working group.

If you want to make a useful Profile, then you delete everything that there is there now, and add "implement the trio, and forget about all the other RFCs that mention Lemonade."  You're deluding yourselves otherwise.

The only IMAP capabilities that are really needed are STARTTLS, LOGINDISABLED, and maybe UIDPLUS.  Mobile devices need URLAUTH and CATENATE.  Everything else is fluff.

-- Mark --

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 25 Jul 2008 12:32:33 +0200

Ned Freed writes:
> I also like the freedom of being able to put the ManageSieve server 
> somewhere other than the IMAP server. In particular, I want the 
> freedom to colocate the ManageSieve server where the sieves 
> themselves are stored, which may or may not be part of the Message 
> Store.

Reminds me of something else. I've mentioned it before but I want to 
harp on this.

Lemonade now tells clients to connect to three separate servers (at 
various times), but offers no advice on how to locate those servers. 
One person (Eric? I forget) thought it was a provisioning issue: The 
client would be correctly configured by the time the user receives it.

I disagree. I think people must be expected to read their mail with 
several devices (at least two — a mobile and something else), and to 
replace these devices occasionally. One of these 2+ devices will often 
be supplied by the service provider, but IMNSHO not all, not even most.

So I think profile-bis ought to say something like «A lemonade client 
can locate its Submission, IMAP and Managesieve servers by taking the 
domain of the user's email address, prefixing it with 
_submission._tcp., _imap._tcp. and _managesieve._tcp., and doing SRV 
DNS lookups for the resulting labels. Lemonade server operators should 
set up suitable SRV records.»

Arnt

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 Jul 2008 07:27:29 -0700 (PDT)

> be supplied by the service provider, but IMNSHO not all, not even most.

+1.

> set up suitable SRV records.»

Well, I don't tnink this properly belongs in a profile specification, but
I'm definitely in favor of specifying it somewhere. in the specific
case of managesieve, where we're talking about an entirely new protocol,
I'd reallly like to see this done in the base specification. This
should probably be discussed on the Sieve WG list though.

				Ned

---

From: Dan Karp <[email-masked]>
Date: Fri, 25 Jul 2008 08:11:53 -0700 (PDT)

> IMAP is already too complex and performs at least one function too
> many (mailbox lists handling). If anything we should be looking for ways to
> simplify it, not ways to cram more stuff into it, especially stuff that's
> largely unrelated to its core mission of providing mail access.

OK, OK, point taken.  My objection was wrong-headed, and I retract it.
If the group doesn't object to ManageSIEVE's inclusion in the profile
based on the additional complexity added to an already-complex set of
requirements, I'm fine with it.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jul 2008 11:30:56 +0100

> Sure, and while we're at it why not put in SMTP submit, and ACAP,  

Oh, we tried putting ACAP into IMAP, we just called it METADATA.

Nobody objected to that, did they?

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jul 2008 16:41:31 +0100

> should probably be discussed on the Sieve WG list though.

SRV records are good, but they require an anchoring domain name for  
use, and only provide hostnames - clients need more than just that.

ACAP is good, too - it supplies considerably more than hostnames and  
ports, it can supply protocol information, email addresses, real  
names, signatures, and more - but the user needs to know where to  
find their ACAP server - and perhaps even more importantly, somebody  
other than me needs to write clients and servers.

XMPP, on the other hand, could provide the above data (XEP-0049 could  
be used now, XEP-0223 is rather smarter, and coming fast) and already  
uses SRV to locate the server from the user identifier, dropping the  
number of data the user needs to remember substantially.

Both XEP-0049 and XEP-0223 essentially allow storage and retreival of  
multiple, arbitrary, mini XML documents on a server, so all we'd  
really need to do would be define an XML formatting of Randy Gellen's  
email and personality dataset classes from ACAP - surprisingly easy,  
really. XEP-0049 is deployed pretty heavily now, XEP-0223 is coming  
fast (and may even be on an XMPP server near you - the keyword you're  
looking for is PEP).

But not a job for today, the profile, or this working group, I think  
- we can make this orthogonal, and given the uptake of XMPP services  
on mobile phones and email clients as a whole, it might even work out  
this time.

Dave.

---

From: [email-masked]
Date: Sun, 27 Jul 2008 11:53:59 +0000

I second Dave's sentiment: 
"But not a job for today, the profile, or this working group."

OMA is doing their own thing. We are not chartered for this. Let's finish and perhaps one can charter a Mail Client Configuration BOF. 

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Dave Cridland <[email-masked]>

Date: Fri, 25 Jul 2008 16:41:31 
To: Ned Freed<[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments<[email-masked]>
Subject: Re: [lemonade] On WGLC: profile-bis [was Re: Proposed Agenda for
 Dublin]

On Fri Jul 25 15:27:29 2008, Ned Freed wrote:
>>_submission._tcp.,_imap._tcp. and_managesieve._tcp., and doing  
>> SRV

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 31 Jul 2008 10:44:28 -0700

At 2:12 PM -0700 7/24/08, Dan Karp wrote:

>  is there no way to find a middle ground that

Adding still more related-but-different functions to IMAP is also a pain.

We could perhaps use Annotate for this.  Or ACAP.  I have a 
(long-since expired) draft on how to manage Sieve with ACAP.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Genetics explains why you look like your father, and if you don't,
why you should.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Thu, 31 Jul 2008 11:05:20 -0700

>  Oh, we tried putting ACAP into IMAP, we just called it METADATA.

Years ago we tried putting the mailbox state part of IMAP into ACAP.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is something fascinating about science.  One gets such
wholesale returns of conjecture out of such a trifling investment
of fact.                                             --Mark Twain
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade