On 7/20/2021 1:13 PM, Barry Leiba wrote:
One of the points of "deprecation" is that we don't eliminate it
entirely, but say that it's no longer used. New implementations no
longer generate it, but implementations that are interested in
backward compatibility will still include support for it on receipt.
Eventually, when we see that its use is rare enough, the community
might move to no longer include suppor
This is a natural, and considerate, model. In the Internet, I believe
it also has been shown not to work. Really.
If something is to be removed from a protocol, it needs to be removed.
So, remove it.
If there is a concern about noting the removal, add an appendix that
references the removed feature, explaining why it was removed, and
citing the previous specification.
Do NOT make it 'deprecated'. Don't continue it's specification. Do NOT
make its use optional. Make its use a matter of private choice, beyond
the four walls of the public protocol specification.
"Deprecated" makes things complicated and conditional. Neither of those
are protocol attributes to aspire to.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
