ietf-mxcomp
[Top] [All Lists]

Re: Towards resolution on Wildcards

2004-06-09 21:55:33

--Ted Hardie <hardie(_at_)qualcomm(_dot_)com> wrote:


At 2:53 PM -0400 6/9/04, Andrew Newton wrote:
In order to reach consensus on the issue of wildcards, we would like
working group participants to answer the following questions.
Please read through them first before responding.

1) During the MARID interim meeting, Ted Hardie suggested a dual
record type approach whereby TXT would be used in servers incapable
of supporting a new record type, but more capable servers would use
a new record type (specifically defined for MARID).  Do you feel
this is a workable solution? (Reference Margaret Olson's description
here: http://www.imc.org/ietf-mxcomp/mail-archive/msg01512.html).

To be a bit clearer here, the group had already agreed that the SPF
syntax might be a fallback to an XML-based syntax standardized in the
group.   It seemed fairly obvious with that deployment strategy that the
SPF record would not move out of TXT into a  special-purpose RR; I
suggested that the XML syntax record might also be present in the TXT
record (in an ascii-only form, to deal with the limitations of some
handlers of TXT records) while we deployed the XML syntax record.


Actually I don't think the group had agreed to use XML as the final format at all. Some members assumed we were, and the rest didn't ask, I guess.

The merged proposal put forth by SPF developers and MS developers says: Allow domain owners to publish either SPF format or XML format. Some people feel that the XML syntax will eventually take over, and we won't need the plain SPF format after a while. However, others feel that the XML format is too complex and weighty.

For my part I am content to let the market decide, in terms of record format, and if we find ourselves with all XML in a couple years, or 99% plain SPF syntax, one or the other can be deprecated.

To that end I propose: A MARID record can be found in either TXT or TYPEXXX, where XXX is the RR type issued to us. The data found there will be plain text (US ASCII) and can either be v=spf1 data or XML data. (In other words I would prefer to divorce the issue of plain text vs. XML from the question of RR type. Both SPF and XML can be used now, and both can be used in the future type.)



Note that in the interim the timeline for full deployment of the new
record was discussed as 5-10 years, and there was explicit discussion of
making parallel queries for both records during that period (presumably
forcing the protocol or deployment docs to discuss what happens if you get
both back and they disagree--already required by a similar possibility of
getting a MARID record back and an SPF syntax record back).


Agreed. Even after the new RR type is published, not all clients will be able to read it. So, some domains will publish both for a long time. To simplify matters, let's say that a MARID RR takes precedence over a TXT RR if both are available, but that it's OK to do both queries in parallel and discard TXT if both are received. The implementor can decide whether to do them in parallel or wait for one to fail in order to try the other.


To re-quote Marshall's now very apropos quote "If not us, who?
And If not now, when?"

Providing a transition strategy that enables us to use TXT as a
short/medium term strategy makes sense to me; relying on it for all time
seems like a collapse into sub-typing where the TXT RR structure doesn't
permit or encourage it.  To put it bluntly, in my opinion it is very bad
engineering.


Totally agreed. We will look silly in 5-10 years if we could have had a new record type and chose not to.

I realize many MS customers won't have a solution right away, but using TXT for now takes the pressure off and gives us some time.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>