[Top] [All Lists]

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

2008-07-30 07:17:07

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.


<Prev in Thread] Current Thread [Next in Thread>