Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields

Michael,

I think it should be made clear what we are talking about when it comes 
to the type of MUA.
There is typical a propensity to think of offline MUA, like Outlook, 
ThunderBird, Eudora, Unix based offline mail readers etc.
But you also have online based MUAs as well.

The difference?

Offline Storage vs Online Storage

Both present a different set of technical and very important legal 
engineering design requirements. 

Obviously, the options for Online MUAs (i.e. WebMail)  are defined by 
what the backend provides the user.    Offline MUA options are defined 
by what the vendors of offline mail writer/reader programs provides.  
The consistency in the options between the two should not be presumed to 
exist.
So I think it is short on design to think that a proposed IETF 2822 
header of this caliber is only useful for offline MUA systems.  The 
design considerations must also be consistent for Online MUAs, including 
Offline MUAs in regards to the stored mail kept on the server which 
generally is the same used for online MUA connectivity as well.
So in my view,  being that we offer a mail process entity for each stage 
of the total mail system, including multiple MUA softwares (offline, 
Online, and Mixed,  text, html and GUI),  I think the question is which 
one processes in the end to end flow process can use this and how.   If 
the proposal mandates the Expire Header is for MUAs only, then for the 
online based MUA, this implies the backend has to support and work with 
it too.
My Point?

It isn't as simple as it might appear when we only consider the offline 
mail write/reader software MUA.  It would be a half baked,  incomplete 
and only partial consideration within the many variant and complete mail 
systems as we know it today.
How about mobile? 

One the key issues here is redundant, wasteful mail  downloads because 
of the "Keep On Mail Server" idea which forces backends to not mark mail 
as received allowing user to get their mail on mobile and back in the 
office/home desktop.
If the Expire Header can be one small additional part of the complete 
process to eliminate "irrelevant" mail,  then it will have a "some" 
payoff for mobile users as well of offline users.
--
HLS


Michael Welzl wrote:
> > So, would you still be happy to have your MUA silently delete 
> > expired  messages?
> Believe it or don't: yes.
> Granted, when I said "silently delete", I meant "silently move it to my
> trashcan folder, which is what my MUA does when I delete emails. This way, if I
> lose something and start to wonder what's wrong, I can still look things up
> in the trash. If I don't start to wonder what's wrong, I believe I have the
> right to assume it's the sender's fault that their message never reached me. 
> This
> is what they risk when falsely setting the expiry date.
>
> Other people could use it to automatically move emails to a suitable
> folder, which makes email reading more efficient and still doesn't
> let them miss the stuff that you mention above. But they can regard
> it as low priority and go through it if and when they consider it
> appropriate.
>
>
>   
> > AFAICS, the only safe way to use 'expire' would either be for it not to
> > move/delete messages at all (in which case, what's the point) or to have
> > different rules handling expire differently from different senders (when
> > you know how THAT sender uses it), but this would only be useful if you
> > repeatedly got expired messages from particular people (which is doubtful)
> >     
> I disagree, on the basis of what I said above.
>
>
>   
> > (I do wonder, how important is this anyway? How often do you receive
> > messages after they would have expired? The only time I can think it
> > would be even slightly useful is if you've just come back from a
> > vacation and haven't checked your mail whilst you've been away, but then
> > a few CFP or talk announcements is going to be irrelevant amongst all
> > the other thousands of semi-junk messages you'll have received!)
> >     
> I agree that this would be especially useful (but not "the only time
> when this would be even slightly useful") after a holiday. The few
> announcements are not going to be irrelevant among the other
> semi-junk things.
>
> Something more time consuming, to give you one more example:
>
> "Michael, please do this until ... messages" - where you have to
> carefully read the whole thing, only to find out that the sender
> has absolutely no use for what he demanded by the time you
> read this message. That happens to me on a regular basis and
> is really annoying.
>
> Putting all of this together, for me and I'm sure that a lot of other
> people, an expired field would be well worth having. You shoudln't
> make your own personal preferences and daily life with email the
> standard.
>
> Probably we (as we discuss on this list) are not even good examples.
> There are newspaper articles and even books discussing how to
> deal with emails, for higher level managers - I'm sure that, for these
> people, any small contribution to reducing the number of daily emails
> is extremely valuable.
>
>
>   
> > I don't have a massive problem with an 'expires' header, I just see it
> > as, at best, pointless, and at worst, dangerous in the hands of an
> > unthinking user (of which there are many using the Internet).
> >     
> Pointless: this is based on your personal preference which you
> outlined above.
>
> Dangerous: no, because of its strictly advisory nature. You would have
> to be unthinking enough to set your mail client to always delete expired
> emails on purpose, then wonder what's wrong. This is equivalent to
> formatting a hard disk on purpose, then wondering what's wrong - that
> a user could do that is the inevitable risk that comes with every
> functionality
> you give him (for once, I think it's actually better to use the male form,
> for
> the sake of political correctness!  :-)   ), but this should not be at the
> cost
> of the rest of us.
>
> Cheers,
> Michael
>
>
>
>