[lemonade] [Technical Errata Reported] RFC5465 (2318)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 06 July 2010 08:12 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: lemonade@core3.amsl.com
Delivered-To: lemonade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5777A3A6A37 for <lemonade@core3.amsl.com>; Tue, 6 Jul 2010 01:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001]
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 0R94p7OVLlmj for <lemonade@core3.amsl.com>; Tue, 6 Jul 2010 01:12:51 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id E72F43A68D0 for <lemonade@ietf.org>; Tue, 6 Jul 2010 01:12:50 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 44D25E0685; Tue, 6 Jul 2010 01:12:53 -0700 (PDT)
To: arnt@oryx.com, Curtis.King@isode.com, Alexey.Melnikov@isode.com, alexey.melnikov@isode.com, stpeter@stpeter.im, gparsons@nortel.com, eburger@standardstrack.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100706081253.44D25E0685@rfc-editor.org>
Date: Tue, 06 Jul 2010 01:12:53 -0700
Cc: lemonade@ietf.org, dwmw2@infradead.org, rfc-editor@rfc-editor.org
Subject: [lemonade] [Technical Errata Reported] RFC5465 (2318)
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lemonade>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 08:12:52 -0000
The following errata report has been submitted for RFC5465, "The IMAP NOTIFY Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5465&eid=2318 -------------------------------------- Type: Technical Reported by: David Woodhouse <dwmw2@infradead.org> Section: 3.1 Original Text ------------- (Time passes. The client decides it wants to know about one more mailbox. As the client already knows necessary STATUS information for all mailboxes below the Lists mailbox, and because "notify set status" would cause STATUS responses for *all* mailboxes specified in the NOTIFY command, including the ones for which the client already knows STATUS information, the client issues an explicit STATUS request for the mailbox to be added to the watch list, followed by the NOTIFY SET without the STATUS parameter.) C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) S: d STATUS completed C: e notify set (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) (mailboxes misc MessageNew) S: e OK done Corrected Text -------------- (Time passes. The client decides it wants to know about one more mailbox. As the client already knows necessary STATUS information for all mailboxes below the Lists mailbox, and because "notify set status" would cause STATUS responses for *all* mailboxes specified in the NOTIFY command, including the ones for which the client already knows STATUS information, the client issues a NOTIFY SET without the STATUS parameter, followed by an explicit STATUS request for the newly-added mailbox. Note that if these two commands were issued in the reverse order, that would be a client bug; changes may occur in the mailbox between the completion of the STATUS command, and the issuing of the NOTIFY command. The client may never be notified of such changes.) C: d notify set (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) (mailboxes misc MessageNew) S: d OK done C: e STATUS misc (UIDVALIDITY UIDNEXT MESSAGES) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) S: e STATUS completed Notes ----- The order of the STATUS and NOTIFY commands is changed. The original sequence is buggy, because any changes to the folder which occur between the two commands will not be noticed by the client. Rather than just fixing it, my suggested correction also highlights the potential error -- if the authors of the RFC can do it, and especially since it's been shown as an example in the RFC until now, then it's worth making sure we highlight the problem. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5465 (draft-ietf-lemonade-imap-notify-07) -------------------------------------- Title : The IMAP NOTIFY Extension Publication Date : February 2009 Author(s) : A. Gulbrandsen, C. King, A. Melnikov Category : PROPOSED STANDARD Source : Enhancements to Internet email to support diverse service environments Area : Applications Stream : IETF Verifying Party : IESG
- [lemonade] [Technical Errata Reported] RFC5465 (2… RFC Errata System