Re: [2822upd] Resent-* MUSTard

Philip Guenther <[email protected]>
Newsgroups gmane.ietf.rfc822
Message-ID <[email protected]>
On Tue, 1 May 2007, Frank Ellermann wrote:
> Pete Resnick wrote:
...
>>> 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'm not sure I would even call the effects of resending vs encapsulating 
_similar_, much less "almost the same".  The very fact that they behave 
differently is a Good Thing, as it means they can express differences in 
intent.  When I want to add someone to a conversational thread, I resend 
to them the latest message (occasionally more than one) so that their 
replies naturally go back to the current set of recipients.  When I want 
to inform someone of something or start a side conversation, I forward it 
to convey that replies probably should go back to me.  They can reply 
however they want, of course, but it conveys my intent and helps avoid 
misaddressing.

Heck, the difference between resending and forwarding is *much* greater 
than the difference between To and Cc recipients.


>>> 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.

That would completely break backwards compatibility, rendering all 
software that generates Resent-* non-compliant.  If your intent is simply 
to break a feature you don't like, please say so.


>> 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.
...
> Here's an older version of the 4409 proposal:
> <http://permalink.gmane.org/gmane.ietf.rfc822/11805>

A clumsy fix is better than a wrong fix.  Off hand, I think discussion of 
Resent-* in a 4409bis should not be restricted to Resent-Sender, as it may 
be appropriate for the MSA to add Resent-Date and/or Resent-Message-Id as 
well.  Also, the last two paragraphs of your suggested change at the above 
URL seem undesirable or out of scope to me.


>> 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.

1) that's not "more functionality"; that's *different* functionality.
    Encapsulation is not a superset of resending.

2) "not forced to use it"  Saying that after you suggest deprecating
    or breaking Resent-* seems disingenuous.


> There's no "Resent-subject", what are you doing that can't be done
> with MIME, threading based on the original references ?

Yeah, you're right, that's *another* feature of resending that 
encapsulation can't reproduce.


Philip Guenther
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.