Scott Kitterman wrote:
In fact, in the latest release of the Python SPF library we disabled
Type99 lookups by default since it was just causing wasted DNS queries.
Is it now shipped with a "this is the conformance test suite, I'm forced
to bahave" heuristics ? <g>
[new RR type]
if we are going to do option 4, we as well save ourselves a lot of
trouble and pack up now and go home. It'll never get deployed.
Depends. One proponent of a future v=spf3 indicated that he would go
for "only in SPF RRs, not in TXT RR", and IMO that makes sense if no
better strategy like Phill's XPTR is available at this time.
a viable technical proposal but it does redefine the semantics of an
existing record. This usage does not cause conflict with any
sanctioned uses but it might well conflict with non sanctioned uses.
I think that shouldn't block it. A larger concern would be would
non-sanctioned uses interfere with this proposal. Does anyone know of
non-sanctioned uses of PTR?
Somebody on "namedroppers" mumbled something in this direction, but IMO
it was neither convincing nor conclusive. We could make sure that any
legacy or idiosyncratic uses of XPTR are still possible and allowed for
folks not interested in the new semantics. Like SPF "allows" to use
TXT as specified for text, with a detailed specification how to find a
say "v=spf1" text if that's what you're looking for, plus considerations
about the size of a complete TXT RR set.
For Phill's (X)PTR this would be considerably simpler, it's mainly a
political question, the technical idea is KISS. I'd feel much better
if a NAPTR expert tells us that (X)PTR is not only simple but also
"the right thing" (tm) for its job.
Solving the general problem you are trying to solve sounds like a good
thing to do, but it's not this Working Group's problem to solve.
IMO that's something for our ADs or rather the IESG to decide, if we
decide to want it. They're free to start a new WG or to propose an
individual submission or to update the Charter or whatever it takes.
They're however not free to suppress ideas just because they don't like
to get into disputes with namedroppers and the IAB (as it would likely
happen in this case). Obviously Jim and Barry need all available ammo
for this approach, minimally a clear WG consensus based on a published
draft.
Getting along does not mean surrender or automatic compromise.
+1
Someone MIGHT already be using _dkim.example.com for some other non-
sanctioned use.
And we are absolutely sure that this is perfectly legal. I can use
this construct for whatever purpose I like. DKIM base doesn't force me
to stay away from "_dkim" labels for other purposes. But of course I
own the "_dkim" pieces when I try to have my cake and eat it too :-)
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html