Murray S. Kucherawy wrote:
It boggles my mind that a specification called DomainKeys Identified _MAIL_
has to be explicit about the fact that the input is expected to be formatted
like a mail message, and that there's even pressure to say in a normative way
that someone implementing this has to make sure that's the case.
Security Considerations of RFC5451 was updated to include language about
hardening against input deliberately crafted to try to confuse or crash
applications, and I was surprised that they (secdir) felt that was necessary;
I expected that to be fairly obvious to anyone in the audience of a standards
track RFC.
(It wasn't required to be normative, however.)
In my view of the IETF RFC documents, its a matter of technical
writing style.
They are neither a 100% Functional Specification nor 100% Technical
Specification, but a blend to help reach a wider audience of disciplines.
A good amount of expertise and/or experience is required to get the
"message" across and it also requires a good amount of
expertise/experience to be able to read the message to both a) extract
and b) extend the engineering insights required to produce the protocol.
In this case, in my technical opinion, Section 5.4 has incomplete
implementation insights regarding the single field requirements for
RFC 5322. It is an insight that would of been included if we had
"seen" the issue when it was first written four years ago, especially
when we went through the TA process.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html