-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please let's continue this discussion on spf-discuss, as it now is really
about the spec, not about implementing it anymore.
Stefano Bagnara wrote:
> > "Stuart D. Gathman" wrote:
> > The grammar for modifier is:
> >
> > modifier = redirect / explanation / unknown-modifier
> >
> > So you can only apply the unknown-modifier syntax if it's not
> > redirect or explanation.
>
> Yes, and that's why the literal "redirect=" is a valid unknown-modifier
> and does not match the redirect modifier. Let me explain:
>
> [...]
> At last we check the unknown-modifier token, defined as:
> unknown-modifier = name "=" macro-string
>
> If you look at the gramma you will find that our "redirect" will match
> the name toke, our "=" will match the "=" and empty string matches the
> macro-string token.
No, no, no. This is all backwards. Again, you're trying to put the letter
of the spec before the intent of the spec. I already tried to explain why
having unknown-modifier match known modifiers is lawyeristic nonsense
- -- no offense.
> > Very cut and dried (although you can complain
> > that it is stupid, and campaign to have it changed for v=spf3).
> > That's why we have a test suite.
>
> I don't agree with this: the rule are in the spec. If the testsuite is
> not compliant with the spec then it is an useless specification. If you
> want to give power to the testsuite then you have to add it to the
> specification.
If you don't think that the test suite can be authoritative, then why do
you even care?
> Please note that I think that what the testsuite expect makes much more
> sense than what the spec grammar declare, but they are clearly
> incompatible, so you should simply add a rule to the specification
> adding one of this:
>
> 1) domain-spec in the grammar should also match the empty string and a
> paragraph in the spec should say that an empty domain-spec => permerror.
No. Why would a domain-spec ever be allowed to be empty? That would be
like saying "let a cidr-length be empty!".
> 2) the name token from the unkown-modifier should be declared so that
> "exp" and "redirect" do not match.
I think this is the direction we're going in.
> 3) Otherwise you'll have to change the whole grammar so that that
> modifier = name "=" macro-string
> And then move all of the logic/syntax specification for the case where
> name matches "exp" or "redirect" outside from the grammar.
Possible, but not nice.
> 4) Change macro-string token definition to:
> macro-string = 1*( macro-expand / macro-literal )
> But I'm not sure about possible side-effects of this change.
> Furthermore this would not fix your current bad interpretation of a
> syntax error in a "redirect=syntax-error" literal (this would be
> recognized as unknown-modifier anyway).
Yeah, let's forget about that one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFr2GswL7PKlBZWjsRAnmiAJ4hizmK7itSmrvBt3iv0a2tufFVLQCeMzn0
5Y2g24M4p5ukiFaAsF+35I0=
=s+Yu
-----END PGP SIGNATURE-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Hash: SHA1
Please let's continue this discussion on spf-discuss, as it now is really
about the spec, not about implementing it anymore.
Stefano Bagnara wrote:
> > "Stuart D. Gathman" wrote:
> > The grammar for modifier is:
> >
> > modifier = redirect / explanation / unknown-modifier
> >
> > So you can only apply the unknown-modifier syntax if it's not
> > redirect or explanation.
>
> Yes, and that's why the literal "redirect=" is a valid unknown-modifier
> and does not match the redirect modifier. Let me explain:
>
> [...]
> At last we check the unknown-modifier token, defined as:
> unknown-modifier = name "=" macro-string
>
> If you look at the gramma you will find that our "redirect" will match
> the name toke, our "=" will match the "=" and empty string matches the
> macro-string token.
No, no, no. This is all backwards. Again, you're trying to put the letter
of the spec before the intent of the spec. I already tried to explain why
having unknown-modifier match known modifiers is lawyeristic nonsense
- -- no offense.
> > Very cut and dried (although you can complain
> > that it is stupid, and campaign to have it changed for v=spf3).
> > That's why we have a test suite.
>
> I don't agree with this: the rule are in the spec. If the testsuite is
> not compliant with the spec then it is an useless specification. If you
> want to give power to the testsuite then you have to add it to the
> specification.
If you don't think that the test suite can be authoritative, then why do
you even care?
> Please note that I think that what the testsuite expect makes much more
> sense than what the spec grammar declare, but they are clearly
> incompatible, so you should simply add a rule to the specification
> adding one of this:
>
> 1) domain-spec in the grammar should also match the empty string and a
> paragraph in the spec should say that an empty domain-spec => permerror.
No. Why would a domain-spec ever be allowed to be empty? That would be
like saying "let a cidr-length be empty!".
> 2) the name token from the unkown-modifier should be declared so that
> "exp" and "redirect" do not match.
I think this is the direction we're going in.
> 3) Otherwise you'll have to change the whole grammar so that that
> modifier = name "=" macro-string
> And then move all of the logic/syntax specification for the case where
> name matches "exp" or "redirect" outside from the grammar.
Possible, but not nice.
> 4) Change macro-string token definition to:
> macro-string = 1*( macro-expand / macro-literal )
> But I'm not sure about possible side-effects of this change.
> Furthermore this would not fix your current bad interpretation of a
> syntax error in a "redirect=syntax-error" literal (this would be
> recognized as unknown-modifier anyway).
Yeah, let's forget about that one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFr2GswL7PKlBZWjsRAnmiAJ4hizmK7itSmrvBt3iv0a2tufFVLQCeMzn0
5Y2g24M4p5ukiFaAsF+35I0=
=s+Yu
-----END PGP SIGNATURE-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007