Re: [2822upd] Resent-* MUSTard

On 5/1/07 at 7:01 AM +0200, Frank Ellermann wrote:

> Pete Resnick wrote:
>
> > 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.
Had I been asked (the appeal never went to the IAB, at least while I 
was there), I would have said that William got his interpretation of 
my comments wrong.
> 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.
Au contraire, I think SenderID plays fast and loose with Resent-*, 
and even if some of the things that it does are fine, some of the 
things it expects  to happen are....shall we say, "experimental". But 
because it is in fact experimental, I don't mind that it violates the 
MUST NOT. If the SenderID experiment succeeds in this respect and it 
turns out that this kind of automatic processing is not like 
"processing replies or other such automatic actions" (in that it 
*can* be done interoperably), then SenderID can become standards 
track, include "Update: RFC 2822" in its masthead, and include a 
paragraph that says, "After experimentation, we have determined that 
the action we do is not like replies or other such automatic actions 
referred to in RFC 2822 3.6.6, and therefore it's OK to use Resent-* 
fields for this purpose." However, like Ned I am suspicious of the 
way the "experiment" is being done. Personally, I think SenderID will 
find that it can't depend on Resent-* for its actions.
So, the current text I think is a correct assessment of the current 
state of the world. If SenderID finds that it is not like replying, 
it can say that.
> How about rewording this statement:
>
> + mainly informational.  They MUST NOT be used in the normal
> + processing of replies or the creation of auto-responses [RFC 3834].
...or creating address book entries or filtering based on author of 
the text or sorting by date or..... Hey, since there's so many things 
that MUAs might automatedly do on messages in which they should look 
at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't 
we say "replying and things like that." Oh.....
> > Resent-* are *never* used when you "forward".
> Sure, but the desired effect is often the same, I got a mail and 
> want you to read it.
No, no, no. That's not what resending is for. As Dave Crocker said 
(in the jabber log noted in William's appeal), "Resent-* was designed 
to splice a new recipient into a direct exchange with the original 
author", not just to send a piece of mail I got to you. MUAs behave 
*very* differently when presented with a MIME-forwarded (or otherwise 
forwarded) piece of mail than they do with a resent one.
The rest of your message I think Philip answered as I would have.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated