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