[Top] [All Lists]

[spf-discuss] Re: Upcoming new test-suite release

2007-12-07 18:55:12
Hash: SHA1

Stuart D. Gathman wrote:
On Fri, 7 Dec 2007, Julian Mehnle wrote:
What about removing my redundant test in favor of an improved
description for the existing "invalid-domain-empty-label" test?  (See
attached diff.)

The "description" field is the "short" description.  It is supposed to
be a one line (or maybe several when quoting ABNF from the RFC)
summary.  The "comment" field is the multiline explanation.

I never understood it that way.  Where do you get that from?  
(<http://www.openspf.org/Test_Suite/Schema> doesn't say it must be a 
one-liner.  It merely says it should not be longer than one or two 
sentences, which my attempt isn't.)

The problem we're getting into here is that we're testing things that 
aren't clearly defined in the RFC, so we have to explain precisely what 
the test is about.  The description should be able to stand on its own 
for someone who knows the RFC well, which isn't easy if the spec itself 
is fuzzy on the test subject.

You are welcome to make the description + comment better, but please
keep the one-line summary + explanatory paragraph format.

OK, I'll give it a shot.

The "invalid-domain-long" test's description has the same problem.
However, I did not want to edit that one before having discussed the
following:  This test tests the "overlong label" case.  But why is it
using macro expansion to that end?  It could just as well say
"a:<64chars>.bar".  That would allow to simplify the description even

See toolonglabel.  You need to test both before and after macro
expansion.  The "spec" field is very informative for why tests are 
there.  The toolonglabel test is for 4.3/1.  The invalid-domain-long
test is for 8.1/2 and 5/10.

"toolonglabel" tests 4.3/1, whereas "invalid-domain-long" only tests 4.3/1 
by analogy at best.  8.1/2 doesn't apply because "invalid-domain-long" 
isn't about a regular syntax error (not even if we change the target-name 
to "<64chars>.bar", which is a valid <domain-spec>).  5/10 doesn't apply 
either, at least not 5/10/2 (the "TempError" case) -- perhaps 5/10/3 
(the "domain does not exist" case), though.

I agree that in the absence of an explicit statement about malformed 
labels, 4.3/1 is a valid analogy.  However, can we please drop the 
reference to 8.1/2, and change the one to 5/10 into 5/10/3?

Then, given that "<64chars>.bar" is a valid <domain-spec>, what's the 
point in having the indirection via some macro, if what we want to test 
is just the handling of malformed (but syntax-valid) domain names?

Version: GnuPG v1.4.6 (GNU/Linux)


Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com