Pete Resnick wrote:
2822 gives no reason why there's an offending MUST NOT about
Resent-* in automatic processing.
2822 does not say that Resent-* "MUST NOT be used in automatic
processing". Don't partially quote. Read it again, in context.
I've read it several times because William quoted it in his appeal
<http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt>
He quoted the "note" adding two references to statements by you.
And he quoted the immediately preceding MUST NOT about Resent-*
in automatic processing as separate argument. If you think that
this "MUST NOT" doesn't affect whatever SenderID does, then the
context needs to be clearer.
As for why: It is because there was confusion about what MUAs ought
to do with those fields, and using them for the reply command, and
"*OTHER SUCH* actions" (was enough emphasis added?) would do the
wrong thing.
How about rewording this statement:
- strictly informational. They MUST NOT be used in the normal
- processing of replies or other such automatic actions on messages.
+ mainly informational. They MUST NOT be used in the normal
+ processing of replies or the creation of auto-responses [RFC 3834].
I use MIME when I forward mails or news, not Resent-*
Resent-* are *never* used when you "forward". That is also said in
quite clearly in 3.6.6 (in the Note).
Sure, but the desired effect is often the same, I got a mail and want
you to read it. I can MIME-forward or resend it to you. With MIME I
can add a reason why I think that it might interest you, with MIME I
can also forward more than mail. But if I don't pick any additional
option offered by MIME the effect is almost the same, you get the
original mail incl. original header and original body.
I don't see why there could be multiple "authors"
So you've backed off of your original argument about the need for
Resent-Sender (because it is needed when Resent-From is not identical
to the sender) and you're just complaining about Ned's example?
Not really. But it would be easy to convince me that the Resent-From
is actually unnecessary, keeping the Resent-Sender.
I think it's more important for interoperability of implementations
to keep the syntax of Resent-From and From identical (and the way
it's always been) than to go verify that nobody is using this
particular feature.
Have you seen my proposed fix for RFC 4409 8.1 ? It's clumsy if there
are both kinds, Resent-From and Resent-Sender. And RFC 4407 also has
its difficulties to arrive at a "PRA" in the presence of both kinds.
Here's an older version of the 4409 proposal:
<http://permalink.gmane.org/gmane.ietf.rfc822/11805>
And I, and a bunch of other folks that I know, will scream bloody
murder if you take that feature out of our mail clients. Forwarding
(MIME or otherwise) does not have the same functionality as resending
MIME has more functionality, you're not forced to use it if you don't
like it. I often send mails with Content-Type: message/rfc822, with
an indicator in the subject why I did that if it's for a human reader.
There's no "Resent-subject", what are you doing that can't be done
with MIME, threading based on the original references ?
Frank