Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> Regardless of format, we need to list the specific attributes for
> testcases. For any of the formats, there are two objects, zonedata and
> testcases. The zonedata has the same attributes as the DNS records used
> by SPF implementations. The testcases have the following attributes so
> far in the ones I have been creating (in the bind syntax):
>
> IP4 string: IP4 connect ip
> IP6 string: IP6 connect ip
> One of IP4,IP6 is required. Should we have a single IP
> attribute and distinguish IP4,IP6 by syntax?

Yes, I'd simply use a unified "host" attribute. Telling IPv4 and IPv6
addresses apart is easy.

> MFROM string: SMTP sender MAIL FROM. Required, may be empty string.
> HELO string: SMTP HELO name. Required.
> RESULT string: Expected SPF result. Required.

All the above (including the "host" attribute) should be case-insensitive.

> SPEC string: SPF Spec reference (like 4.5/2). Optional.

Can someone suggest a few cases where a spec reference would be impossible
or inappropriate? Should multiple spec references per test be allowed or
forbidden?

> COMMENT string: Short comment explaining purpose of test. Optional.
> COMMENTS stringlist: Long multiline comment. Optional.

Note: >
At least in YAML, multiline text doesn't have to (and shouldn't) be
represented as an array/set of separate strings. I'd suggest storing a
long comment as a single block of text.

> ZONEDATA zonedata: testcases are implicitly assigned the last zonedata
> set in the input stream. Required, may be empty.

The "last set in the input stream" referencing is impractical in JSON and
YAML. I'd prefer some kind of structural link between zone data and
tests, e.g. by defining every "test scenario" to always consist of a set
of DNS records plus a set of tests. (A test scenario is a YAML document
in my YAML example, and I see a similar structure in your JSON example.)

> Julian, were you planning to have your annotated SPEC be the source, and
> extract test cases from it automatically? Or were you planning to
> auto-insert testcases from our dataset based on the SPEC attribute?

I think we should perhaps not add test data directly to the annotatable
spec at all. Automatically extracting test data from the annotatable spec
might be possible but probably isn't worth the trouble. Instead it might
be worthwhile to write a quick test-data-to-HTML converter that just links
to the spec's anchors, and provides anchors for the spec to link to.

That way the spec text and test data wouldn't have to be intermixed, and
the HTML-formatted test data could be kept in sync with the raw svn file
by a cron job.

Comments?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEpdBvwL7PKlBZWjsRAp1kAJ9F+TFf2A4taAXetrnQRCUKkBaVIwCbB2TX
XZ/51a91o/y7pWj4t1h52Xs=
=zgf5
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com