Sean Leonard <dev+ietf(_at_)seantek(_dot_)com> writes:
When I raised the classification issue during initial development, one
advisor said something to the effect of oh, so it's like a Real BCP,
where it actually prescribes actual Best Current Practices, unlike what
most of the BCPs these days are. (Whatever that means, just the messenger!)
In re Dispatch, I knew that its scope had been broadened, but had
In re "BCP", the reference is RFC 2026 section 5, "The Internet
Standards Process -- Revision 3" ... which is itself a BCP. What it
says is that BCPs are *standards* not for protocols but for *things that
people do*. So in regard to your draft, the "thing that people do" is
"write code that validates e-mail addresses for further processing".
And the point of your draft is that people need to write correct code
for validating e-mail addresses.
Here's another ugly little bit of processing: On some systems, library
routines that convert dotted-number IP address strings into four-octet
format treat a component that starts with "0" as being written in octal.
E.g., "010.010.010.010" is equivalent to "126.96.36.199". (Try executing "dig
ietf.org @010.010.010.010" on a Linux system.) As far as I know, this
isn't *specified* anywhere in the RFCs, and some RFCs (e.g., RFC 997)
have leading zeros on numbers that contain "9". So it's worth warning
people not to use leading zeros in IPv4 addresses.
I can see a lot of value in cleaning up this mess. If it's possible to
not make (many) systems stop working, it would be worth making the new
version normatively update the existing specs.
ietf-smtp mailing list