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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf