Mark wrote:
If we can get this thing passed with wording that says:
"NOT RECOMMENDED", then that, to me, will suffice for now.
Sure, But no tricks like "not defined", "undesirable", or
"undocumented". senderid-core-00 has a SHOULD. Therefore
anything weaker than a SHOULD NOT, MUST NOT, SHALL NOT, or
NOT RECOMMMENDED won't fly. I certainly don't insist on the
stronger MUST NOT or SHALL NOT.
| "Other identities SHOULD NOT be checked against v=spf1
| records, this can have misleading or unintended results."
Good enough, and this clearly restricts itself to v=spf1, no
remotely possible confusion with spf2.0/pra sender policies.
It struck me as a bit odd, that when the RFC Editor makes a
sugesstion to tone words down, that our reaction would then
be to do the exact opposite and propose an even stronger
wording.
If it helps him to explain why he proposed to castrate v=spf1,
where's the problem ? As soon as that's discussed you can use
the original NOT RECOMMENDED (= SHOULD NOT),
I've quoted RfC 2119 and its advise about "actually required
for interoperation or to limit behavior which has potential
for causing harm". This not only justifies a MUST NOT, it's
an ethical imperative if you know a potential for causing harm.
"NOT RECOMMENDED", for the time being is good enough for me.
Then we agree on this point and can forget your "undocumented"
proposal.
I propose we seek clarification on the matter, with the RFC
editor (if it was really him, and not a note *to* the RFC
editor).
Seconded, please do this. It was AFAIK a note *by*, not *to*,
the latter would make no sense, he cannot edit documents as it
pleases an unknown third party. Only Wayne and Meng can edit
their memo. Please keep this list informed about the outcome.
Bye, Frank