Re: [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: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@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, 09 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: [apps-discuss] New draft at MORG: POP3 LIST+ Extension
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-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
- [apps-discuss] New draft at MORG: POP3 LIST+ Exte… Steffen Lehmann
- Re: [apps-discuss] New draft at MORG: POP3 LIST+ … Barry Leiba
- Re: [apps-discuss] [MORG] New draft at MORG: POP3… Mark Crispin