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

Hi,

I don't understand your point. I wholeaheartedly agree that
online MUAs should also be supported - so what? I don't see
how this affects the rules that Keith Moore beautifully
laid out in this email:
http://www.imc.org/ietf-822/mail-archive/msg06348.html

In our University's webmail system, I can define folders
and set some filters; by default, the system should only
highlight expired emails somehow (which it could), and
it might allow me to automatically have them deleted,
or moved somewhere...

I just don't see a difference with regards to usage
of the expiry date.

Cheers,
Michael


On Wed, 2008-07-23 at 19:56 -0400, Hector Santos wrote:
> 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
> > 
> > 
> > 
> >   
> 
>