John C Klensin wrote:
Let me remind this group about earlier notes from Lisa and Tony:
we have agreed to do this work as an effort to create RFC2821bis
and move it to Draft.
TINW. I'm mainly interested in the "fix known errors + wordsmith
unclear prose" parts at the moment, without accusations to belong
to any "2821-to-DS" cabal. If the result is a 2821bis better than
2821 it's good, its status is another question.
A suggestion to revisit and revise protocol decisions made in
RFC822 and affirmed in RFC2822 or made in RFC821, clarified (in
this case) in RFC1123, and affirmed in RFC2821 are simply out of
scope.
That's okay from my POV, and it would even cover the known issues
of something involuntarily _broken_ by 1123.
people could have introduced standalone proposals to change mail
semantics at any time, gotten consensus if it was to be had, and
then pushed their work through to Proposed Standard.
Yes, the efforts to preserve RFC 821 semantics as good as possible
(after RFC 1123 broke the <reverse-path> concept) took some time,
and ended up with some rather baroque "features" after an IETF WG
chartered to get this right was terminated unilaterally. That's
all known and on public record, why do you start again with it ?
I don't recall a single article from you in MARID, it's certainly
not your fault. OTOH it's also not the fault of these folks if
the WG is terminated unilaterally, if a requested IETF Last Call
isn't granted, if requirements for PS apparently needed something
better than 1,000,000 domains and ten inpedependent interoperable
implementations (in this case), if a technically incompatible
proposal (violating MUSTard in 2822) is approved, and if an appeal
to fix at least this incompatibility (by removing four characters)
didn't manage to get this result.
What else did you expect, somebody testing the recall procedure ?
A "process failure" appeal to ISOC ? "We" (that's not your "we")
certainly tried to follow the rules (and still do). And besides
Brian tried to discuss the problem of incompatible "experiments"
after this experience on the general list.
Back to the issue at hand (2821), I proposed to rip the complete
historical part (source routes, SEND, SOML, SAML, etc.) out of it
several times and never got any feedback supporting this approach
to cut RFC 2821 into managable pieces, not from you, and not from
anybody else where I proposed this. With one exception posted in
<http://article.gmane.org/gmane.ietf.lemonade/199/raw>
| *Do not* bother raising the issue of reorganizing the document
| once again, and/or breaking it up into separate pieces. Such
| emails will be summarily ignored.
Of course I ignore this article. Are we now ready with ranting
for today ? Fixing ABNF oddities is more fun than these flames.
Frank