On Wed, 11 Nov 1998, Tim Showalter wrote:
My understanding of the DRUMS discussion on Resent-* headers is that
they are not to be used for .forward style automatic, unconditional
forwarding, but are supposed to be used for user-initiated forwarding.
I say that Sieve falls into this latter category, and thus Resent-*
headers SHOULD be generated.
Okay, I'm not sure if I agree with the first half, but I can accept the
second half in any case.
Actually, I disagree with Randy here. My take on the DRUMS decision was
that Resent-* headers are for User Agent manual resends. If Sieve is
running on an IMAP server, then Resent-* headers shouldn't be generated,
IMHO.
My take, arrived at independently, is that Chris is reading DRUMS correctly.
In addition, we've found that generation of Resent-* fields isn't a good idea.
We generated Resent-* fields as a result of automatic forwards for around 10
years. And throughout that time we had regular reports of problems with it --
some agents use Resent-* fields preferentially, often with poor results,
multiple sets of Resent-* fields are inherently problematic, various MTAs have
funny ideas about what constitutes a "correct" set of Resent-* fields and
bounce what they think of improperly formatted messages, and so on.
But we persevered because RFC822 certainly encourages this practice as part of
forwarding, and we felt that not documenting such forwarding actions was poor
practice.
But then along came DRUMS, which relgated these fields to the status of trace
information and for user agents. And so we decided to stop generating them to
match up to the standard-to-be.
And guess what? It seems there was downside to this. It seems that nobody
really wanted the fields to begin with, so while a bunch of problems went away,
no new ones cropped up.
So now I don't think these fields should be used for automatic forwards under
any circumstances.
I've implemented them, but I suspect there may be implementation
environments where this is hard to support, and so I don't think we can
require it.
Really? Could you provide an example? I can think of only one, and I
think it's rather absurd.
Chris, why shouldn't this be "SHOULD"? I think SHOULD would be useful
since I assume short-circuit evaluation will be required by extensions
that specify tests with side effects, and it's useful from an efficiency
standpoint.
There is no justification to use SHOULD. Either programmers can rely on
short-circuit behavior or they can't. The former is MUST, the latter is
MAY.
I don't think the existance of environments where short-circuit evaluation
isn't possible constitutes justification for making the language flexible in
this way. Either short-circuit evaluation is useful enough to standardize, in
which case it should be a MUST, or it isn't, in which case we should say that
you MUST NOT assume the language does it and leave it at that.
A MAY in such cases will encourage people to use short-circuits as a language
feature when they find it works. And this will lead to interoperability
problems when scripts are written assuming it.
My personal take is that short-circuit evaluation is useful enough to warrant a
MUST. But I'd rather have a statement saying scripts MUST NOT take advantage of
short-circuit evaluation than one saying implementations MAY do it.
Ned