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

> How about this: "The sender believes this message will be irrelevant
> after the indicated date/time."

If memory serves, this matches the X.400 definition pretty closely. (Note that
the X.400 definition isn't something you'll find in any RFC - the various
X.400-related RFCs only define mappings, for the most part the specification of
X.400 field semantics is left to X.400 itself.)

> "This field is primarily intended for use between senders and recipients
> and their agents, rather than by message transport.    It is suggested
> that the default behavior of an MUA with respect to the expires header
> field should be to display such a message in a distinguished way.  For
> example, the message could be displayed with gray text rather than
> black, or in a different font than normal, or (in summaries) with an
> image of an hourglass with the sand at the bottom."

> "It is also suggested that MUAs allow setting of an expiration date as
> an option when composing messages"

I wonder if it is worth saying something about how it is RECOMMENDED that the
user be allowed to pick from a calender or some other graphical tool rather
than always having to type in a date directly... OK, probably not.

> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis
> of an Expired header field unless given explicit instructions to do so
> by the recipient."

> "Mail Filters MUST NOT consider an expired header field as criteria to
> be considered for deleting the message unless given explicit
> instructions to do so by the recipient"

This text seems very reasonable to me.

> behavior for mail-to-NetNews gateways should also be specified.

If someone wants to write it, sure, but I don't think defining this mapping is
a prerequisite to this specification being viable any more than I think a
mapping to MMS or any other serivce email is routinely gatewayed into is
required.

				Ned