Re: [2822upd] Resent-* MUSTard

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