[neomutt-devel] [neomutt/neomutt] Add support to IMAP custom keywords (#399)
gahr at gahr.ch
Fri Feb 17 16:46:08 CET 2017
On 2017-Feb-17, 16:22, guyzmo wrote:
> moving the discussion over the ML.
> On Fri, Feb 17, 2017 at 01:27:38AM -0800, Pietro Cerutti wrote:
> > It is my interpretation of the standard and current custom that IMAP
> > Flags are meant to carry **client**-specific info such as colouring
> > (Mail.app) or implementation-specific labels (`Junk`, `NotJunk` in
> > GMail).
> > This is in contrast to the `X-Label` header, which is meant to carry **user**-defined tags.
> I don't think a difference shall be made. Yes, IMAP flags are carrying
> some information used by the client, but in the end that information is
> user-defined. There's just some UX in the other MUAs to hide the
> implementation details.
The information used by a client application to generate the content of
the flag might be used-defined. The content itself most definitely
> > There are in my opinion two consequences that come from this difference:
> > 1. IMAP Flags should be machine-readable, whereas `X-Labels` should be
> > user-readable. This is also clear from the fact that IMAP Flags have a
> > well-defined syntax, while X-Labels can take wathever value a header
> > can, including being encoded in something different than us-ascii.
> As shown in documentation¹, X-Labels have been standardised in the
> RFC2822 as comma space delimited keywords in the `Keyword:` header, and
> the labels implementation of mutt supports that.
I don't see rfc2822 mentioning space. They are a comma-separated list of
"phrase". As per rfc2047, they could carry encoding information and text
in whatever language in whatever charset. IMAP Flags most definitely
> All in all keywords and labels are meant to be both human readable and
> machine readable, because in the end they're used directly or indirectly
> bu an user to lookup and/or group e-mails.
I don't agree with the first part of this sentence. IMAP Flags are meant
to be machine readable and understandable. I still have to see a client
that displays them as they are and allow modification in a free-form
textbox. Again, they are *used* by client application to store specific
On the other hand, I don't think any client does anything particular
with Keywords, other than displaying them as-is and allow to change
As a side note, while this documentation suggests an option to use the
standard Keywords header, a quick look at the code (grep OPTKEYWORD)
suggests that this feature is not implemented. The options are there,
but are not used anywhere.
gahr at gahr.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1020 bytes
Desc: not available
More information about the neomutt-devel