Mailing List Archive

On Mon, 7 Aug 2006, Julian Mehnle wrote:

> I also made some minor corrections to the YAML test data files, most
> notably to the indentation of the zonedata records, which was invalid
> (I think):
>
> http://www.openspf.org/source/project?rev=18&view=rev

Just checked, and zonedata was already correct - and your revision
shows no changes to zonedata.

We have a stylistic disagreement. You like to change:

description: |
A lengthy line of description that would look ugly when wrapped over lines.

to

description: A lengthy line of description that would look ugly when wrapped over lines.

I really prefer having the '|' even when the description actually fits.
I would like to have the description consistently on another level.

You also like to change '|' to '>-' for multi-line descriptions. I can
go along with this if it is actually a paragraph that should be reformatted.
But often it isn't.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

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

Stuart D. Gathman wrote:
> On Mon, 7 Aug 2006, Julian Mehnle wrote:
> > I also made some minor corrections to the YAML test data files, most
> > notably to the indentation of the zonedata records, which was invalid
> > (I think):
> >
> > http://www.openspf.org/source/project?rev=18&view=rev
>
> Just checked, and zonedata was already correct - and your revision
> shows no changes to zonedata.

That seems to be an overly diligent optimization of ViewCVS. Do a

$ svn diff -r17:18 rfc4408-tests.yml

...and you'll see what I did. At least Perl's YAML module claimed that
the old formatting was invalid. I haven't had the time to examine the
YAML spec, but I think it looks more clear _with_ the extra indentation
anyway.

> We have a stylistic disagreement. You like to change:
>
> description: |
> A lengthy line of description that would look ugly when wrapped over lines.
>
> to
>
> description: A lengthy line of description that would look ugly when wrapped over lines.
>
> I really prefer having the '|' even when the description actually fits.
> I would like to have the description consistently on another level.

OK. It's an entirely cosmetic issue, though.

> You also like to change '|' to '>-' for multi-line descriptions. I can
> go along with this if it is actually a paragraph that should be
> reformatted. But often it isn't.

Then let's use the '|' (literal) block style only when necessary, and '>'
otherwise. In any case, I think we should use '-' (clipping), because we
really don't need trailing newlines. So let's use '>-' and '|-', OK?

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

iD8DBQFE2ERVwL7PKlBZWjsRApsVAJ9o5CXcJzU3szJhDqdf6AbmwSiKrgCgiDpc
xpuhLU8Ki+HeEMT7vIzWDQE=
=G/fZ
-----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

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

Julian Mehnle wrote:
> I created a preliminary formal Relax NG schema:
>
> http://www.openspf.org/source/project/test-suite/schema.rng?view=auto

I have been thinking about the <no-synthesis> element...

| ...
| <element name="zonedata">
| <zeroOrMore>
| <element name="domain">
| <zeroOrMore>
| <grammar>
| <start>
| <choice>
| <!-- A DNS resource record: -->
| <element name="record">
| ...
| </element>
|
| <!-- Or a default error/timeout: -->
| <ref name="error-or-timeout"/>
|
| <!-- Or a SPF/TXT synthesis suppressor: -->
| <element name="no-synthesis">
| <optional>
| <attribute name="type">
| <list>
| <oneOrMore>
| <choice>
| <value>SPF</value>
| <value>TXT</value>
| </choice>
| </oneOrMore>
| </list>
| </attribute>
| </optional>
| </element>
| </choice>
| </start>
|
| <define name="error-or-timeout">
| <choice>
| <!-- An <error>: -->
| <element name="error">
| <attribute name="rcode">
| ...
| </attribute>
| </element>
|
| <!-- Or a <timeout>: -->
| <element name="timeout"><empty></element>
| </choice>
| </define>
| </grammar>
| </zeroOrMore>
| </element>
| </zeroOrMore>
| </element>
| ...

I think we don't actually need it both ways, i.e. <no-synthesis type="SPF">
_and_ <no-synthesis type="TXT">. It should be sufficient to always just
synthesize TXT records from SPF records, not the other way round, right?
So only <no-synthesis type="TXT">, or in short, <no-txt-synthesis>, would
be required.

In YAML syntax:

| zonedata:
| spfonly.example.net:
| - SPF: v=spf1 -all
| - NO-TXT-SYNTHESIS

instead of

| zonedata:
| spfonly.example.net:
| - SPF: v=spf1 -all
| - TXT: NONE

Comments?

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

iD8DBQFE34oMwL7PKlBZWjsRAmxEAKC6OjrtKIwvsCLmYbidUU2lvJjoRwCcDzHa
1BWhzUKGCwxFpNq7eW9aZzA=
=Noj2
-----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

On Sun, 13 Aug 2006, Julian Mehnle wrote:

> I think we don't actually need it both ways, i.e. <no-synthesis type="SPF">
> _and_ <no-synthesis type="TXT">. It should be sufficient to always just
> synthesize TXT records from SPF records, not the other way round, right?
> So only <no-synthesis type="TXT">, or in short, <no-txt-synthesis>, would
> be required.

I agree.

> In YAML syntax:
>
> | zonedata:
> | spfonly.example.net:
> | - SPF: v=spf1 -all
> | - NO-TXT-SYNTHESIS
>
> instead of
>
> | zonedata:
> | spfonly.example.net:
> | - SPF: v=spf1 -all
> | - TXT: NONE
>
> Comments?

The TXT: NONE syntax has the great advantage that it works even if
the test driver doesn't test for it. (Non SPF TXT records don't
affect things, although we verify this with some other tests.)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

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

Stuart D. Gathman wrote:
> On Sun, 13 Aug 2006, Julian Mehnle wrote:
> > I think we don't actually need it both ways, i.e. <no-synthesis
> > type="SPF"> _and_ <no-synthesis type="TXT">. It should be sufficient
> > to always just synthesize TXT records from SPF records, not the other
> > way round, right? So only <no-synthesis type="TXT">, or in short,
> > <no-txt-synthesis>, would be required.
>
> I agree.

Ok, I updated the RNG schema accordingly (r21).

> > In YAML syntax:
> >
> > | zonedata:
> > | spfonly.example.net:
> > | - SPF: v=spf1 -all
> > | - NO-TXT-SYNTHESIS
> >
> > instead of
> >
> > | zonedata:
> > | spfonly.example.net:
> > | - SPF: v=spf1 -all
> > | - TXT: NONE
> >
> > Comments?
>
> The TXT: NONE syntax has the great advantage that it works even if
> the test driver doesn't test for it.

How so?

I can only see this "working" under the assumption that TXT synthesis is
implicitly suppressed as soon as _any_ TXT record is found for the domain
in question (be it NONE or "v=spf1" or "foo"). Is that what you're
thinking?

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

iD8DBQFE4LRRwL7PKlBZWjsRAup4AJ96QWEV9G8LWqmG+yorFULkrtZAwACfeUjo
eebHIBeWYRqgVOqu8LEDKGo=
=FVDP
-----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

On Mon, 14 Aug 2006, Julian Mehnle wrote:

> > The TXT: NONE syntax has the great advantage that it works even if
> > the test driver doesn't test for it.
>
> How so?
>
> I can only see this "working" under the assumption that TXT synthesis is
> implicitly suppressed as soon as _any_ TXT record is found for the domain
> in question (be it NONE or "v=spf1" or "foo"). Is that what you're
> thinking?

Yes, that is the explicit requirement of the informal test suite spec.

Another advantage of this scheme, is that if you ignore it entirely
(no record sythesis at all), then you get correct results for
"SPF only" and "BOTH" implementations (only "TXT only" fails). So a
modern implementation that is going to check for type 99 records anyway
doesn't need to worry about the record synthesis stuff at all.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

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

Stuart D. Gathman wrote:
> On Mon, 14 Aug 2006, Julian Mehnle wrote:
> > > The TXT: NONE syntax has the great advantage that it works even if
> > > the test driver doesn't test for it.
> >
> > How so?
> >
> > I can only see this "working" under the assumption that TXT synthesis
> > is implicitly suppressed as soon as _any_ TXT record is found for the
> > domain in question (be it NONE or "v=spf1" or "foo"). Is that what
> > you're thinking?
>
> Yes, that is the explicit requirement of the informal test suite spec.
>
> Another advantage of this scheme, is that if you ignore it entirely
> (no record sythesis at all), then you get correct results for
> "SPF only" and "BOTH" implementations (only "TXT only" fails). So a
> modern implementation that is going to check for type 99 records anyway
> doesn't need to worry about the record synthesis stuff at all.

Ok, I got the point. :-) This rationale and test driver implementation
hint probably should be documented in the test suite docs.

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

iD8DBQFE50skwL7PKlBZWjsRAvelAJ9iKbzdUyLsBnRuYOe5VBXdfpEMPgCglq6P
tP0g+cs+abM4+kWaL1Dr/70=
=pr2X
-----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