In <1098074595(_dot_)3572(_dot_)214(_dot_)camel(_at_)localhost> Andy Bakun
<spf(_at_)leave-it-to-grace(_dot_)com> writes:
Okay. But I'm still having problems with the complexity of domain-spec
being defined in terms of macro-string.
For what it is worth, in my current version, I have simplified the
ABNF to:
domain-spec = macro-string domain-end
domain-end = ( "." 1*ALPHA ) / macro-expand
This is due to both Frank's and your comments.
This is functionally equivalent to the stuff in -pre2.
Everything except the last macro-expand is consumed by the leading
"*(macro-string)", and can only be, since B doesn't allow a macro-expand
to directly follow a period (and as you pointed out above in response to
my first issue), making the '"." 1*ALPHA' redundant.
Right.
[...] As such, isn't
*( macro-string ) 1*( ( "." 1*ALPHA ) / macro-expand )
equivalent to
1*( ( "." 1*ALPHA ) / macro-expand / macro-literal )
No.
The latter will accept "foo.com/24" as a domain name. This is a
problem because the "/24" is supposed to be a CIDR spec.
The problem is things like the ABNF for the mx: mechanism:
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
During the MARID discussion, it was correctly pointed out that
"mx:foo.com/24" is ambiguous because the ABNF for the domain-spec
could swallow up the entire string and not leave the "/24" for the
CIDR ABNF to parse.
Mark fixed this problem by making it illegal to have a slash in domain
names. As I pointed out in a earlier note, slashes are not only valid
for domain names, but recommmended in one of the RFCs.
My change allows slashes, just like earlier specs, but requires the
domain to end in either a dot followed by at least one letter, or by a
macro variable.
Obviously, I think my solution is better. I dunno what others think.
Is the intent to force domain-spec to always end with strings that don't
contain macros or to end in a macro? This seems like an odd way to go
about this, and an odd restriction to boot (since, logically, a
domain-spec can only ever end in either a macro or a series of literals,
as there is no other possibility).
I think you almost had it there, but backwards.
This stuff is *UUUuugly*.
Again, I'll ask for comments about whether support for this invalid %
escape stuff that MUST NOT ever be used should be just eliminated from
my doc and as a result, create syntax errors instead.
I think it depends on if you actually want to list both the things that
should match and the things that don't or just list the things that
match and then make the claim that things that don't are not valid. It
seems odd to me to have a definition of macro-expand-invalid for the
sole purpose of saying that invalid constructs are parse-able but should
cause an error. Is there a difference between "unparse-able" (and thus
not usable) and "isn't an allowed syntax" (and also not usable)? In
terms of error reporting, I suppose, but isn't that something that
should happen in a validator, not in an evaluator?
In my current draft, I have declared these invalid percent escapes to
be syntax errors.
I tried creating correct ABNF to handle all the cases correctly and to
keep the semantics found in the spf-draft-200406, but it got *real*
messy. While it isn't completely backwards compatible, I think the
problems caused by allowing them outweigh the problems caused by
removing them.
It certainly cleans up the spec.
Shouldn't the ABNF list the valid macro letters rather than use ALPHA
in: [snip]
I notice that Frank Ellerman has mentioned this already in
<4172FB01(_dot_)219E(_at_)xyzzy(_dot_)claranet(_dot_)de>.
Yes, and I've fixed this in my current draft.
An example of multiple delimiters (since macro-expand contains
"*delimiter") would also be helpful:
Hmmm... As Mark likes to say, the spec should not be a how-to, but I
can see your point. I'll have to think about this one a little more
and see...
I am of the opinion that the combination of prose and examples provide
more information and enforce each other more than either one would
convey alone.
I agree, although some of this can be better done by a test suite
which can be updated rather than being placed in the spec.
I'm still thinking on this.
-wayne