MBOX-Line: From slusarz at curecanti.org Mon Jan 7 20:05:10 2013 To: imap-protocol@u.washington.edu From: Michael M Slusarz Date: Fri, 08 Jun 2018 12:34:50 -0000 Subject: [Imap-protocol] Re: Missing UIDNEXT during mailbox synchronization In-Reply-To: References: <20121228112725.Horde.cM7EjLQoqQDix9dQMs5KcA1@bigworm.curecanti.org> <20130106223402.Horde.ZSCj1mxY7M87XW6Ro4AX9A1@bigworm.curecanti.org> Message-ID: <20130107210510.Horde.qsaKFcRqd9QLEChauk461g3@bigworm.curecanti.org> Quoting Barry Leiba : >>> Looks like that part of 3501 was not updated from 2060, then -- the >>> UIDNEXT is listed as REQUIRED in the description of the SELECT command, as >>> Bron pointed out. >> >> I reported this as an errata to RFC 3501, with the recommendation that the >> "assumption" sentence from the UIDNEXT text be removed in order to eliminate >> the ambiguity between this text (which implies that the UIDNEXT response may >> be optional) and the REQUIRED requirement located in Sections 6.3.1 & 6.3.2. > > Um... > > But this erratum is wrong. You jumped to premature conclusions. Sigh. I *KNEW* that UIDNEXT was not required for some reason - I had just forgotten the logic & explanation. For some reason I forgot that RFC 2060 is also IMAP4rev1, NOT IMAP4, so there are several backward compatibility concerns between the two documents. > Look at the paragraph above the responses in Section 6.3.1. It says this: > > The SELECT command selects a mailbox so that messages in the > mailbox can be accessed. Before returning an OK to the client, > the server MUST send the following untagged data to the client. > Note that earlier versions of this protocol only required the > FLAGS, EXISTS, and RECENT untagged data; consequently, client > implementations SHOULD implement default behavior for missing data > as discussed with the individual item. I'd still argue that labeling the PERMANENTFLAGS/UIDNEXT responses an unqualified REQUIRED in the SELECT/EXAMINE description is, at best, confusing - this thread being proof of this fact. (I will note the UNSEEN response has already been modified in an errata to handle a similar case where UNSEEN is REQUIRED... unless it isn't.) However, this critique is more of an extremely tardy editorial comment rather than an errata. > The text that you're suggesting removing is there very purposefully, > and should NOT be removed. I intend to mark the erratum as > "Rejected", but I'll give us some time to discuss it further first. I don't think further discussion is necessary. You are correct - it should be rejected. Wishing there was an "unsubmit" button on the submission page... Sorry for the noise, michael