John C Klensin wrote:
(2) Decide that source routes are ancient history and remove
Appendix C entirely, moving all discussion of source routes
into the present F.2, and shifting the rules for forward-
pointing source routes from "MAY ignore" (and use the Mailbox
information and MX records only) to "SHOULD ignore".
Good direction. My proposal was "outsource all cruft to a
separate document", but "put anything in F.2" is also fine.
But don't remove the A-d-l syntax for paths, I think you want
"MUST NOT generate, MUST ignore", but still also "MUST accept"
for this cruft. Why only "SHOULD ignore" ? It can't work as
designed in RFC 821 if it's generally not generated. RFC 1123
even went so far to say that it never worked as designed... :-(
Reintroducing source routes and requiring support for them
would, of course, constitute adding functionality
Folks would know where to find RFC 4408, in a certain sense it
reintroduces the lost reverse routes. RFC 4408 also claims
that source routes are "archaic", my appeal about this insult
was rejected... ;-)
The current working version of -03 incorporates a version of
option (1) above.
I'd like option (2) better. I could quote the "reverse path"
design as it was in 821 when necessary no matter which option
you pick in 2821bis - it's a philosophical thing about what
"responsibility" means for forwarders to third parties, and
what it means for MSAs accepting a MAIL FROM (4409 6.1). And
why the name "return-path" was NOT a stupid error that should
have been "bounces-to".
Frank