On Sun, 2004-10-17 at 15:02, wayne wrote:
Uh, because macro-string can be repeated zero or more times, and "/"
means alternation (regular expressions use "|" or "\|" instead of
"/"). I'm pretty sure I don't understand what you don't understand
and so I don't understand how to help you. (other than by writting
confusing sentences. ;-)
Heh, 18 hours later reviewing this, I can't remember exactly what I was
trying to get across, but I am completely sure that, in this instance,
it wasn't about ABNF syntax! :) But I think it was related to...
[domain-spec definition]
The leading variable repetition operator is redundant. I think it
should be removed from macro-string, since domain-spec is meant to match
the whole entity, and macro-string is meant to only match a specific
substring of that.
I think the redundant repetition operator should be removed from
domain-spec, not macro-string, and have done so in
draft-schlitt-spf00. macro-string needs to keep its repetition
operator because it is used elsewhere.
Okay. But I'm still having problems with the complexity of domain-spec
being defined in terms of macro-string. In Section 8.2, one of the
examples is:
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
which matches the following series of expressions:
macro-expand %{lr-} A
macro-literal . A
macro-literal l A
macro-literal p A
macro-literal . A
macro-expand %{ir} A
macro-literal . A
macro-expand %{v} A
macro-literal . A
macro-literal _ A
macro-literal s A
macro-literal p A
macro-literal f A
macro-literal . A
macro-expand %{d2} B
(where A is the first half of domain-spec, "*(macro-string)", and B is
the second half, "1*(("." 1*ALPHA) / macro-expand)")
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. As such, isn't
*( macro-string ) 1*( ( "." 1*ALPHA ) / macro-expand )
equivalent to
1*( ( "." 1*ALPHA ) / macro-expand / macro-literal )
? And if not, what does the former match that the latter doesn't, and
what does the former not match (that it shouldn't) that the latter
does? But even this simplification still does not _obviously_ allow
macros to follow a period. The fact that macros can follow periods is
hidden in the expansion of macro-string. I think domain-spec could be
simplified even further, and be clearer, as:
1*( macro-expand / macro-literal )
since
"." 1*ALPHA
is a subset of
1*macro-literal
and there is no reason why non-alpha can not follow periods (as
'1*macro-literal' allows it). The inclusion of '"." 1*ALPHA' seems to
imply something that actually isn't the case.
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). If the intent is to not allow
constructs like "%{x}x" and only allow macros to be delimited by
periods, then this won't work. They are still possible due to part A
doing most of the consumption of the input. If these are valid
restrictions then maybe this should be the definition of domain-spec:
*( macro-string ) ( ( 1*("." 1*ALPHA ) ) / macro-expand )
which is a slight, but important, variation on the current one:
*( macro-string ) 1*( ( "." 1*ALPHA ) / macro-expand )
(with macro-string having the variable repetition operator depending on
if it was removed from the definition of macro-string). Both of the
above allow:
%{l}.x%{d} user.xexample.com
%{l}%{d} userexample.com
%{d}%{d} example.comexample.com
Is this the intent? With properly constructed macros and unfortunate
domain names, this is a potential DOS.
It appears that macro-string and domain-spec are, currently, effectively
exactly the same. I have a feeling I'm missing something important here
(sorry if I'm being obtuse, reply privately if you don't want to
continue to clutter the list with my misunderstanding).
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?
BTW, Section 8.1 says:
Any unrecognized macro letters are syntax errors.
Shouldn't the ABNF list the valid macro letters rather than use ALPHA
in:
macro-expand = ( "%{" ALPHA transformer *delimiter "}" )
/ "%%" / "%_" / "%-" / macro-expand-invalid
Should an implementor need to refer to the prose for what's valid in one
case (which macro letters are valid) and not in another (what
macro-expand-invalid is)? This is more a question of RFC draft style
than a specific critique.
I notice that Frank Ellerman has mentioned this already in
<4172FB01(_dot_)219E(_at_)xyzzy(_dot_)claranet(_dot_)de>.
An example of multiple delimiters (since macro-expand contains
"*delimiter") would also be helpful:
<sender> is j(_dot_)random+folder(_at_)email(_dot_)example(_dot_)com
%{l} j.random+folder
%{lr} random+folder.j
%{l.+} j.random.folder
%{lr.+} folder.random.j
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. The mention of multiple delimiters is kind of short in
the prose and could be easily skipped. Additional examples help provide
test cases for what needs to be supported. Although I acknowledge that
it can be tough to keep the two in sync, thereby increasing the chance
of errors and contradictions, it can still be valuable in reduction of
divergent implementations. But this is your decision.
Andy Bakun
spf(_at_)leave-it-to-grace(_dot_)com