Lyndon Nerenberg wrote: > $Work, $Personal: > > Is there a need to standardize these? It seems to me that the > reason for $* flags is to ensure functional compatibility > between clients. I cannot think of any functionality that would > be triggered by these flags.
None. The same is even true for $Junk/$NotJunk. $* flags are not necessarily about automatic processing, they are about special client behavior or special handling by the server. > All they're really useful for is > narrowing the view on a folder, and that can be done using > any user flag. And for that sort of narrowing, having just > these two flags is much too restrictive. If my mail is > varied enough to require this sort of markup, odds are good > that I'm going to be using a more fine-grained set of > categories (e.g., work.sysadmin, work.benefits, personal.kids, > personal.carinsurance). I think we can design an arbitrary complex set of rules and never agree. Couple of mail clients (Mozilla and I believe Eudora) use this labels, this suggests they are usable. > I don't think these two should be standardized. > > $Important > > This section attempts to define both the Priority and X-Priority > RFC 2822 headers. This is completely out of scope for this > document I don't mind reference an existing document. > (and simply cannot be done in the case of X-Priority). Most things can be done :-). > The two paragraphs that refer to these headers must be removed. They > could be replaced by text that suggests the delivery agent might > want to set this flag based on examination of the RFC 2822 headers > (but should not specifically refer to Priority or X-Priority). Ok, I will think about this. This flag is supposed to be automatically settable by the server (delivery agent or IMAP), so it has to document which headers are to be used. > $Adult > > The two MUSTs must be changed to MAYs. We're defining a tool, > not a code of behaviour. I've already agreed to remove $Adult. > $Spam > > I think better functionality is achieved using $Junk and $NotJunk. > The latter provides a mechanism for the user to override the server's > or client's categorization. This is required functionality. The way > Apple Mail handles this is for the client to set the Junk flag when > its internal spam filter triggers on a message. If I decide the message > is not spam I can hit a button that says "this isn't spam" which then > sets the NotJunk flag, and clears the Junk flag. If, at a later time, > the client needs to resync the folder for some reason (causing it to > re-apply the spam filter tests), the NotJunk marked messages won't > get re-classified as spam. Yes, $Spam will be replaced by 4 (or 5) keyword as suggested by Chris Newman and others. > $Forwarded > > Is this really useful in real life? Without knowing who the message > was forwarded to, and when, I don't see much practical value. This > information is better stored using annotate. I am not too sure myself. Is an indication that the message was forwarded useful in general? Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________
