Re: Scope for self-destructing email?

[John C Klensin <[e-mail]>]

--On Wednesday, August 16, 2017 09:49 -0700 Ted Hardie
<[e-mail]> wrote:


> On Tue, Aug 15, 2017 at 9:50 PM, vaibhav singh
> <[e-mail]> wrote:
>...
>> *why not try to accommodate both realitys and define a
>> feature which is called "Invalidation of Messages" or similar
>> instead of "Destructible Messages". The goal of this feature
>> should be to mark messages in a way, that the client somehow
>> can mark the message as "not being relevant anymore" or
>> something like that.
>...

> I think there are two potential lines of development here,
> though I confess I am skeptical of the value of either.

> The first is providing a facility that declares a particular
> message to be automatically overcome by events at a particular
> time, leaving it completely up to the recipient how to process
> the message based on that metadata.  There are simple message
> types (today's weather, lunch availability, etc.) that could
> be thus set to be marked OBE when no longer relevant.  Some
> clients might choose to auto-delete them or auto-archive them
> when the time is reached, but this would be because of their
> preferred handling and not a guarantee to the sender that the
> sender's intent is being honored.  A message header like
> OBE-At: could be registered provisionally without much hassle,
> and you could see if it saw implementation and use.

Ted,

Do you consider the above significantly different from the
X.400-derived Expiry-Date (RFC 1327) or Expires (RFC 2156)?
While both are identified as obsolete in RFC 4021 and the IANA
Message Header registry, they provide a date and leave it up to
the recipient how those metadata are processed.

While RFC 1327 and 2156 primarily define those fields by
reference to X.400 (1988 and 1992), my recollection of the
CCITT/ISO documents is that the expiration date-time is defined
in a way that is quite consistent with "Invalidation of
Messages" as described above, with the receiving system free to
warn about obsolescence or even to discard copies.

While I don't think it has much of a future --for reasons that
many of us have given and that I assume are consistent with your
skepticism -- I'd like to propose what I think would be a far
more constructive approach for Vaibhav and colleagues than
continued iterations on the IETF list:  They could write an I-D
in the form of an Experimental document that would actually pin
down what they are proposing.  That I-D could propose changing
the "obsolete" status for "Expires" in the registry to something
more active if the experiment succeeds, eliminating the need for
any IANA or Expert action at this point and potentially taking
advantage of any MUAs or MTAs that haven't bothered to get rid
of support for those old headers.   Then, with the feature and
any needed protocol bits specified, they see if they can get any
real traction.  Under more usual circumstances, we'd publish an
experimental spec without implementations and demonstration of
usefulness and usability, but, since "Expires" was implemented
and deployed in the past, after which the IETF decided it was
obsolete, it seems to me that pursuing this further should
require proof of utility and/or a clear explanation of why this
time is different.

best,
    john