mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:36 -0000
Message-ID: 09f60ca2b6755b2ede231d31ee4ce55e@iki.fi permalink / raw / eml / mbox
RFC says:

       It is permitted to delete a name that has inferior hierarchical
       names and does not have the \Noselect mailbox name attribute.  In
       this case, all messages in that mailbox are removed, and the name
       will acquire the \Noselect mailbox name attribute.

But is it really wanted that the mailbox still exists and has 
\Noselect? I'm guessing this should mean that when doing LIST "" %, it 
shows up as \Noselect since it has children, but LIST "" * shouldn't 
need to show the mailbox at all since it shows its children anyway?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20050723/7fe2a140/attachment.sig>
Reply
E-mail headers
From: guenther+imap@sendmail.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:36 -0000
Message-ID: 200507231418.j6NEI3MW043522@lab.smi.sendmail.com permalink / raw / eml / mbox
Timo Sirainen <tss@iki.fi> writes:
>RFC [3501, section 6.3.4] says:
>
>       It is permitted to delete a name that has inferior hierarchical
>       names and does not have the \Noselect mailbox name attribute.  In
>       this case, all messages in that mailbox are removed, and the name
>       will acquire the \Noselect mailbox name attribute.
>
>But is it really wanted that the mailbox still exists and has 
>\Noselect? I'm guessing this should mean that when doing LIST "" %, it 
>shows up as \Noselect since it has children, but LIST "" * shouldn't 
>need to show the mailbox at all since it shows its children anyway?

Correct.  This is already corrected via an erratum.  The RFC editor
keeps errata lists for RFCs; their list for RFC 3501 can be found at
	http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3501

However, that's slightly out of date; the current list can be snagged
from
	ftp://ftp.cac.washington.edu/imap/rfc3501-errata


Mark: the rfc3502-errata file in that same directory has the same
text for old vs new.  1988 -> 1998?


Philip Guenther
Reply