-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
ACK, but if he's working with an API where he never sees the extraneous
NUL it's bitter.
Then he's just not using a sufficiently low-level API. I know nothing
about the Win32 DNS API, and it may very well be tough to handle null
bytes properly, but it's certainly possible. On the other hand, I'd
hardly call the protocol police if his Win32 SPF implementation tolerates
trailing null bytes. Not nice, but not big trouble either.
Some days ago I read a draft where TXT RRs were used for a completely
different purpose, some appletalk / bonjour magic to note properties of a
service in name=value pairs.
They use the "subdivisions" of TXT to delimit the individual pairs. In
the SPF spec. it's explained how such strings have to be concatenated
without adding an intervening space. If that strategy is used with their
stuff they'd get garbage:
0x03A=B0x05AA=BB would result in A=BAA=BB, and following their spec. that
would be a single name A with value BAA=BB. Now I'm curious: Is the way
how SPF handles TXT "unusual", or is Apple idea (no explicit delimiter) a
bad idea ?
Well, the semantics of TXT are obviously undefined in RFC 1034/1035. It
was supposed to be a free-text record with no technical meaning.
The fact that SPF overloads TXT with clearly defined semantics is certainly
unusual, as is this other (Apple) thing. Fortunately we now have the SPF
RR type.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE9o9xwL7PKlBZWjsRAt/2AKD/tXZ4nDMhymNonAph25Frp2z51wCbBifa
h9b57Rgn3ziWCC933jVub2o=
=s9tH
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com