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
