In <20050707203729(_dot_)GA25708(_at_)alatheia(_dot_)elm(_dot_)net> Alex van
den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> writes:
On Thu, Jul 07, 2005 at 03:27:16PM -0500, wayne wrote:
If you parse "*all" as the directive, you end up with one of these:
"" "*all" where qualifier is empty and mechanism is error
"*" "all" where qualifier is error and mechanism is known
Best match would be one invalid character "*" and three valid
chars "all". Your way of thinking results in four invalid chars
Ah, ok, I think I understand your point now. In either case, the ABNF
in the spec requires this to be a syntax error, the question is "what
kind of syntax error?".
Indeed. And IMHO it is best to leave no possible ambiguity
in a spec --> I say it is an omission.
Well, the spec is unambigous about how valid input must be treated and
it is unambigious about what input is invalid. It says what to do in
this case, and that is to return a PermError.
As far as what additional information generated by a validation tool
should give, I think that is out of the scope of the spec. I think
that can be a *very* hard problem. Creating good diagnostic messages
means having to understand what the user probably meant, and
understanding what people think is a hard problem.
Consider the unknown/invalid mechanism "al". Is that supposed to be
"a" that had an extra "l" stuck on it,or is it "all" with one "l" left
off? If it is part of "al:foo.com", you can be pretty sure it was
supposed to be "a", and if it was at the very end of the record, it is
more likely to be "all", especially if it was "-al".
What if it is "a11"? Is that supposed to be "a/11", or "all"?
What about "pall" with "p" being close on the keyboard to "-"? Should
that be consider an unknown qualifier, or an unknown mechanism?
I really don't think we want to go into this area in the spec.
This is the bane of most compilers. What is the correct error message
for "al"? or "?al"? or "*al"? or "?-all"?
"Garbage '?-all' found where directive expected" perhaps?
But it isn't really garbage. Maybe someone just forgot to delete on
of the qualifiers, or maybe someone is confused and thinks that you
can return two qualifiers.
"Clearly" they intended for the mechanism to be "all", right?
One minor point. You refer to "your way of thinking" and such, but
I'm not Scott and I didn't write Scott's validation tool. If you just
mixed up who ways saying what, no problems. If, instead, I'm confused
or you are trying to make a different point that I've missed, please
let me know.
Well, wasn't it you who asked how the spec was unclear w.r.t.
qualifiers ? If not, sorry, it was indeed a mixup then.
Yes, I did ask, but I don't think that the spec is ambigious here.
The spec says to return PermError. That is all we need to specify.
However, I'm open to ideas. Can you provide a patch to the spec that
will clean up all these cases where a validation tool may not give the
"right" results?
If you come up with something short, and simple and well liked by
others, I would certainly consider it. And, like last time,
objections to the changes for the "48hr Author Review" by the RFC
Editor can be appealed to the SPF Council.
-wayne