J.D. Falk wrote: > Charles Lindsey wrote: > >> All of them are a proper subject of discussion, should this WG decide to >> embark on such a BCP (and the misunderstandings repeatedly displayed here >> seem to suggest that something of the sort is needed). > > Agreed, except for one thing: until there's a larger set of users of ADSP, > no practice can be said to be common. > > A "considerations for use" document might help, though I'm not sure what it > could say that the RFC doesn't already cover.
The issue is about codifying the existing but conflictive semantics to prevent problems and maybe even help to lay the ground for wider adoption across the board. One part says "THAT is possible." Another part says "THIS is possible." Whats missing in THIS is: "Oh by the way, if you do THIS, you need to maybe check THAT because THIS will break THAT and THAT will break THIS." That is all I am noting here and IMO, the "correction" will allow for wider consideration and new implementations to at least be consistent and please note, I am speaking of only about intermediaries. If that was agreed and added, at lease from this small lonely developer perspective, I will be comfortable, enabled our compiler directives "#define SUPPORT_DKIM", recompile and instantly offer DKIM/ADSP support in our next updates. At least few thousand operators will instantly have the feature offerings. I will be comfortable because when an ADSP standard violation happens by some other system, we can then pass the buck and throw the book at them. :) -- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
