Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])

Tony Finch wrote:

>> the author can't say "updates 2822", how should he fix it ? 
>> As you said the 822 issue is mentioned in the senderid-pra
>> draft.

> Regarding RFC 822, the S-ID draft doesn't mention the fact
> that a large proportion of software which does something
> useful with Resent- headers still implements the 822 syntax,
> not the 2822 syntax.

Except from all PRA-purposes and maybe MUAs displaying these
Resent-* header fields somehow (822 or 2822):  What other uses
do you have in mind ?

Maybe that was discussed somewhere in MARID last year, in that
case I either missed it or didn't get it.

A related issue, apparently 2822 twisted the syntax (more than
one Resent-* block allowed) _and_ the semantics.  Dave's "old"
822 concept could reflect "forwarding" (maybe - I'm not sure).

If that's true 822-Resent-* and PRA are semantically similar,
the only missing piece would be to either allow more than one
"block" (like 2822), or "invalidate" old Resent-* header fields
somehow, e.g. William's Original-* idea.

While I'm at it:  How's that supposed to work with RfC 2476bis
8.1 "MAY add Sender" ?  Apparently 2476bis 8.1 is still based
on the old 822-concept of Resent-* (?)

Or does it ignore the issue ?  Is this part of the PRA-mess in
fact "our" fault (for a definition of TINW including everybody
who reviewed the gellens-submit drafts) ?

Of course I watched 2476 6.1 (and also 8.1), it's essential for
stuff like draft-hutzler-spamops or "op=auth", but something
with Resent-* is very odd, and it's not necessarily PRA.  Bye

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf