Subject: [apps-discuss] New draft at MORG: POP3 LIST+ Extension

From: Steffen Lehmann <[email-masked]>
Date: Thu, 03 Feb 2011 16:30:50 +0100

Hello,

there is a new draft at
http://datatracker.ietf.org/doc/draft-lehmann-morg-pop3listplus/
describing the "POP3 LIST+ Extension".

Although it is related to POP3 instead of IMAP, I have put it into MORG,
because MORG's goals are fitting best.

Comments and suggestions are solicited.

Steffen

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Feb 2011 11:45:48 -0500

> because MORG's goals are fitting best.

[Barry, as chair]
I'll add, for those who aren't aware, that Steffen approached the MORG
chairs to ask if it were appropriate to discuss this draft on the MORG
list, and we said that we think it is.  That does not mean that the
document will be picked up by the MORG working group, which is
wrapping up its work and is not likely to recharter.  But we think the
right people will see these messages on the MORG and APPSAWG lists.

[Barry, as participant]
I like this draft, and I think it would have been a useful extension
if presented years ago.  I'm not sure how useful it will be now; as
Mark has pointed out, it'll be hard to get implementations, and then
hard to get everyone to upgrade or change to server and client
versions that support it.

Most modern servers and clients support both POP and IMAP, and need no
changes to have users switch to IMAP (especially for the more involved
functions that are being discussed on the other thread.  I think it's
likely to be easier, when users need to use your servers as
large-scale message stores, with their clients holding local caches
and doing complex synchronization, to give those users instructions on
switching to IMAP, rather than to have them change their client
software (upgrade or switch entirely).  Reconfiguring for IMAP is a
few-minute task with little risk, and clear instructions for doing it
on the most popular clients can be published, minimizing the support
costs.

Further, switching users to IMAP is a much more robust solution than
trying to make POP into a sort of "IMAP light".  I *strongly* advise
against that, and suggest that the discussion going on in the other
thread is not useful.  But even this modest version, which is clever
and concise, and which makes perfect sense, is unlikely to be useful
in practice for several years, at least, and may well never get enough
deployment to be useful.

I'd feel much better if we saw a bunch of client and server
implementors post here and say that they'd implement this soon, if it
were standardized.  In particular, on the client side, unless this is
implemented in Outlook, Thunderbird, and Apple Mail (all three), I
think it's swimming upstream.

To the spec itself: as Mykyta says, the IANA considerations section
needs to be made into proper instructions to IANA, if this goes
forward.  I recommend that you not bother with that until we're more
certain that it will go forward... the IANA details can be filled in
later.

I see one technical point that I wonder about:
The combination of AGE and UNREAD *almost* tells you what you need to
know, I think.  If AGE > UNREAD, you know the message was downloaded,
perhaps on another client.  But if AGE == UNREAD, you aren't sure.  It
would be nice if that were clear.  Perhaps a special value of UNREAD
(such as "-1") would work to indicate that the message has never been
RETRieved.  (And, yes, as Timo points out, the spec should make it
clear what "read" means, even if it says that it's an implementation
choice.)

Barry

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 Feb 2011 09:05:33 -0800 (PST)

> in practice for several years, at least, and may well never get enough

Indeed.  There is little, if anything, technically wrong with this
document.  It is well written, and well thought-out.

It is simply (at least) 15 years too late.

Unfortunately, no matter how technically excellent a specification may be,
a specification that is too late is doomed to failure.

Barry is being kind in saying that it "is unlikely to be useful in
practice for several years, at least, and may well never get enough
deployment to be useful."  The reality is harsher.

-- 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.