I want to not constrain the document to the point where it does not reflect
the complexities of the reality in which we find ourselves.
Assuming I've counted your negatives correctly, I think I understand what
you want, and although it is a perfectly reasonable way to write one's
code, it's not a good way to write a standard.
People do all sorts of stuff, much of which we can't anticipate. Trying
to guess all the ways that people will use or abuse standards just leads
to confusion.
While I understand your desire, let there be room for people do try what
what works, and to adapt to circumstances.
Sure, but you don't write the implementation guide into the standard.
You limit it to the rules to interoperate. That's why the SMTP standard
doesn't say oh, you could also use uucp.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html