RE: Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt

Is there any objection to a new flag with explicit semantics of importance?
The meaning of \flagged is private between a client and it's store.  The
importance is a sender-indicated message attribute, not a recipient
indication of a particular level of interest or importance they may wish to
recall between sessions. We need a flag that is standardized by convention
between a message deposit process that can set this flag and the many
different clients that would expect the flag to be there if a message is
tagged as important. 

I think use of a new flag makes plenty of sense for \important.  I don't
think a flag per message context makes much sense tho.  

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email protected]]
Sent: Friday, April 26, 2002 8:31 PM
To: John Neystadt
Cc: [email protected]; [email protected]
Subject: [VPIM] Re: I-D
ACTION:draft-neystadt-imap-status-counters-00.txt


On Fri, 26 Apr 2002, John Neystadt wrote:
> BTW is \Flagged semantics is really "importance". If I
> make my server (by Sieve or other mechanism) turn \Flagged on all messages
> with "Importance: High" header, would that be ok. What are other uses for
it
> today?

What \Flagged does is client-dependent, but the basic idea is to mark some
kind of "importance" emphasis on the message.  In the original MM program
on the DEC-20, flagged messages were always announced with every new mail
announcement.  In more modern message-browser type programs, flagged
messages are drawn with a box around them or in a bold font or with some
sort of highlighting color to call attention to it.

Since VPIM is essentially a client application, it is perfectly within its
rights to decide that \Flagged means "Important" in the VPIM context, and
to decide that the MDA should turn on \Flagged on all messages which have
"Importance: High" in the header.  In fact, I could see some non-VPIM
users wanting to do that in the MDA.

I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
much as possible rather than try to extend STATUS.  One thing that you
could try to do is use STATUS to identify whether a mailbox should be
subject to more detailed examination with SELECT+SEARCH.  That was the
original intent behind STATUS; to enable identification of "interesting"
mailboxes without having to SELECT them.

The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

Also, the more minimal a VPIM extension to IMAP is, the more likely it is
that you'll get it generally implemented.  For example, if a VPIM
extension requires only about 15 minutes of programming work, I'm likely
to do it in my server, just to preclude having to answer an email require
to do it.  If, on the other hand, an extension requires many hours of
work, it's much less likely to happen without specific value to us.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

"A single glass of champagne imparts a feeling of exhiliaration.  The
nerves are braced; the imagination is agreeably strirred; the wits become
more nimble.  A bottle produces a contrary effect.  Excess causes a
comatose insensibility.  So it is with war; and the quality of both is
best discovered by sipping."  -- Winston Churchill



----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo