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

Barry Leiba <barryleiba@computer.org> Wed, 09 February 2011 16:45 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: morg@core3.amsl.com
Delivered-To: morg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3C13A65A5; Wed, 9 Feb 2011 08:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEx-f5R4rN5J; Wed, 9 Feb 2011 08:45:39 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E7F333A63CA; Wed, 9 Feb 2011 08:45:38 -0800 (PST)
Received: by iym1 with SMTP id 1so364238iym.31 for <multiple recipients>; Wed, 09 Feb 2011 08:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKXBZ/BAEP3NaV7TK4POoMHVtx9ZArm5Lzd4wHqZPg0=; b=gkyHaqst0/PcbU3UDpZHaoDh36gIhiXTbpSCwi8sfIXPoX59f4uOfzQAOzXxv5C+vU 9e9RTAXjqsNVnuGWP7AW0VBmpcxkbMRK4MxzAVrlhFY/gcAccJZavn+f83/EoglNiPRd y0NspE85OMCTrTn5u2iiDZ8CiFl4AmxoTZgcM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=E9DPUhcgX/zTg7BvmvG89CxVXSCf3V9uAXJHuoga4miLBw3Yb7dVxRqqU8zLNIov8+ gsg5v0mtAbc4WV9/yt/PlBT0KT6PpbNPt5ktJjLjmKy4SdYcAhqpWhE/mq15bfCEyXyA wAyhIYVFOeM7qUppcno/IpfobVhviOsLVuJlY=
MIME-Version: 1.0
Received: by 10.42.221.4 with SMTP id ia4mr22012665icb.400.1297269948564; Wed, 09 Feb 2011 08:45:48 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.42.228.74 with HTTP; Wed, 9 Feb 2011 08:45:48 -0800 (PST)
In-Reply-To: <4D4ACA2A.3080401@strato-rz.de>
References: <4D4ACA2A.3080401@strato-rz.de>
Date: Wed, 9 Feb 2011 11:45:48 -0500
X-Google-Sender-Auth: 29QKpaURe1I42BasahfXvei5maA
Message-ID: <AANLkTi=aiBjixP4UsBzTPij13L_W0dLHdcq=S-KrBU07@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Steffen Lehmann <lehmann@strato-rz.de>
Content-Type: text/plain; charset=ISO-8859-1
Cc: morg@ietf.org, apps-discuss@ietf.org
Subject: Re: [MORG] [apps-discuss] New draft at MORG: POP3 LIST+ Extension
X-BeenThere: morg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Messaging Organization <morg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/morg>
List-Post: <mailto:morg@ietf.org>
List-Help: <mailto:morg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2011 16:45:40 -0000

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

[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