Frank Ellermann wrote:
Keith Moore wrote:
then we disagree. IMO, it's nearly always a disservice to
the Internet community for us to define a standard way to
do an undesirable thing.
I think we don't necesarily disagree about this principle,
we apparently disagree that it is applicable for "Expires:".
An undesirable thing here would be applications ignoring the
MUSTard in your proposed semantics. But suppressing an idea
because fools could intentionally ignore MUSTard is IMO odd.
It depends on how widespread such foolishness is.
1. Face it, most people don't know that RFCs even exist, so they have no
idea whether their service providers, MUAs, or message stores conform to
the MUSTs in those RFCs. And while most implementors probably know that
RFCs exist and are capable of finding them, many of them won't bother to
do enough research to find the "right" RFC for something like Expires
that seems to have an obvious meaning. Especially when there are
several RFCs that mention the use of Expires in a different context.
This is the downside to having plain language header field names, and to
reusing existing field names from other protocols/contexts.
2. There's also a strong tendency among implementors for creeping
featurism, to add features that don't need to be there. Even if we say
that mail transport and message stores MUST NOT delete messages on the
basis of this new field without recipient consent, implementors of such
products will have a hard time resisting the temptation to add such a
feature which seems obviously useful to them. It's mostly an ego thing,
I think, but I don't see much hope in fixing it.
3. And there's still the problem of communicating what this means to
users. If we name the field "Less-Relevant-After" then user agents
still need to give users the ability to set this field when composing
mail, and they still need to give users the ability to search for such
fields, flag such messages for deletion, etc. and message stores need
to give users the option of deleting "less relevant" messages. It
doesn't matter what we write in the RFC if users don't use the RFC.
They'll just use the field in whatever way makes sense to them -
assuming user agents give them ability to do so.
--
Really I think it mostly comes down to this: Market conditions have
resulted in crippled email user interfaces with no obvious way to
improve the situation. So whenever we talk about adding another field
that gives users more control over messages or more flexibility, we're
faced with the possibility that we'll see more implementation of this
field (incorrectly) in message transport and message stores than we see
in user agents.
That doesn't mean we shouldn't define new fields. But maybe we ought to
think hard about what's wrong with email user interfaces and what we can
do to help unwedge them. Rather than adding one new field at a time
maybe we should consider what new features users really need, what it
would take to make them usable, and what protocol extensions would help
support them.
Keith