John Levine wrote:
"ADSP records always start with 'dkim=', syntax:
There aren't enough bulldozers in the world to drain
this swamp.
s/always/MUST/ is a cheap bulldozer. Add a SHOULD NOT
for wildcards. See the relevant RFC 4408 section 3.1.5,
"not recommended" + "discouraged", at this time RFC 4592
was still a draft. But the SPF folks knew those drafts.
"Depending on the size of all wildcard TXT records
combined the DNS reply won't fit into an UDP datagram,
and might not make it to the party interested in the
ADSP TXT record."
No kidding. The IETF has so far carefully avoided the
disreputable practice of inventing faux record types by
subtyping TXT with a prefix string. (SPF and Sender-ID
don't count, being experimental.)
SPF got its own record type, in theory the IETF -- ignoring
the missing Last Call and the bogus status -- danced around
the issue. And "subtyping" SPF DNS records works to some
degree. It's no brilliant new idea, other DNS record types
have similar features.
If you have a SHOULD NOT for wildcards the "protocol police"
can't get you. After a "MUST start with dkim=" limited to
this case ADSP could work as far as TXT wildcards can work.
The UDP issue isn't as hot as it was four years ago, EDNS0
is expected to work today, e.g., for IPv6.
starting with the non-existence of a prefix registry
For the reasons you have noted there never will be a prefix
registry for TXT records. There will be a registry for SPF
records as soon as somebody invents a new SPF subtyppe. Or
if the author of the spf-options draft bothers to post a new
version of his I-D after with very simple conclusions about
two years of "experiments" with five subtypes plus an option
instead of precisely two subtypes without option.
Of course that won't help you for ADSP TXT records. But you
don't need a subtype registry for the SHOULD NOT fine print.
every newly defined prefix would increase the chance of
overflow, thereby breaking the users of existing prefixes.
When publishers violate a SHOULD NOT they need to be aware
why they do this, and of the limitations. It is entirely
their problem, for SPF they can limit the TXT record usage
with wildcard TXT "v=spf1 redirect=elsewhere.example" (33
bytes in this example, let's say 120 bytes for two fairly
long xn--whatever.example redirects for both SPF and PRA).
Were we to do this, we'd get the spec kicked back with
advice telling us that if we want a new RR type, define
one. And they'd be right.
The WG decided against subtyping SPF records for various
reasons. And it wants the _adsp below _domainkey feature
for valid reasons in the case of ordinary (non-wildcard)
records. Anybody trying to kick WG decisions documented
in several tickets from different folks (Dave + me, IIRC)
has a problem.
Phil posted a complete superwildcard draft to tackle this
issue, it's not that "we" (TINW) have no ammo if somebody
riding his hobby horse tries to play polo with ADSP.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html