On Mon, 29 Aug 2005, Frank Ellermann wrote:
incompatible with RFC2822
I'm still a bit lost how this could actually _break_ something.
For obvious reasons 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.
Do you want more "security considerations", something along
the line of "PRA-participants agree to break an explicit MUST
in 2822" ?
Its not that easy because participants are not the only ones who
see messages from such forwarders (if they ever come into existence)
and so as I mentioned the draft actions are not limited to those who
agree to participate in the experiment (but at least and unlike
re-purposing of v=spf1 records this action would not cause failures
as you correctly note).
And since this actually breaks standard, this would seem to require
explicit action and consent from IESG with understanding about it
and update to RFC2822 with consensus and last call if properly done
(and there has not been even an attempt by draft authors to ask for
review at ietf-smtp or ietf-822 and do last-call like SPF draft
author has done voluntarily). I guess its also fundamental question
on how seriously does IETF really protect its own standards and
follows its own procedures on how they are to be changed.
As far as fixing it there are two ways to go about it (and you're
correct that I should have mentioned considering its an appeal and
there I have to say, not only what I believe is wrong but how it
can be fixed):
1. As I already mentioned, IETF can do separate draft that updates
RFC2822 and illuminates ambiguities allowing for reuse of Resent-
header fields by forwarders. This new draft (and only that draft)
would have to go to standard track as proposed standard with appropriate
review and last call same as RFC2822.
2. Without changing standard, SID for its experiment (and since
none of the systems adding Resent are adding it the way they want
right now anyway, so no changes to running systems) can just create
new header field and use that - this possibility has been mentioned
at MARID btw.
--
William Leibzon
Elan Networks
william@xxxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf