Inline.
At 1:46 PM -0500 8/10/04, wayne wrote:
In <p06110400bd3eb6b156f7(_at_)[67(_dot_)161(_dot_)18(_dot_)242]> Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> writes:
At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote:
While such a change is, from the standpoint of architectural
purity, absolutely the correct thing to do, I fear that in
practice it may lead to confusion, needless duplication of
records, and a failure to achieve the intended objective.
In other words, it is my opinion that engineering
considerations do not weigh in favour of changing the string.
I particularly do not want to see a world where the norm is:
example.com TXT "v=spf1 a mx ptr"
example.com TXT "v=spf2 a mx ptr"
Both records would contain the same content, yet senders
might feel the need to publish both "just to be on the safe side".
Both records do _not_ contain the same information. The first
record has a target of MAIL_FROM; the second has a target
of PRA. The fact that the strings "a mx ptr" happen to be
the same in both records does not change that fundamental
fact.
*sigh*
1) Meng said that they "contain the same content", not "contain the
same information". You appear to be confusing content with
information.
No. I chose the word information to contrast with "content".
I wish to highlight that their containing the same string
does not mean they are answering the same question.
2) Meng, and many others, have pointed out that in the vast majority
of cases, the information *will* be the same and changing the
version number will cause far more problems than it solves.
I don't think so. They have tried to say "the answer to the two
questions would be the same", which is not the same as
"the information will be the same". The answer to the question
"What is the last name of the current occupant of the U.S.
presidency?" and "What is the last name of the artist whose
debut album was 'The Kick Inside'?" may be the same,
but Bush, George W. and Bush, Kate are not the same.
As I pointed out in the recent face-to-face meeting, re-using
the same version string to answer a different question creates
a problem for those deploying these systems: they must
understand how their string would be understood as an
answer to either question. Given that we hope this will
have very wide deployment, and given that cost gets paid
by every domain from now on, this is a high price. As
I channeled John Klensin at the mic, don't look at the current
deployment, look at the rate of deployment to make this call.
The fact that the same IPv4 dotted quad might appear in
an MX record and NS record for example.com doesn't change
the fact that the records tell you different things about how
that domain's systems are set up. The situation here is
parallel; it isn't as obvious because you're using the overloaded
TXT record rather than the new RR.
This has *NOTHING* to do with RR types. The same problems would exist
if we were talking about changing
example.com TXTspf1 "a mx ptr"
example.com TXTspf2 "a mx ptr"
That is, deleting a few characters and moving a quote doesn't change
anything.
I personally think this is a lot clearer that the two records are answering
different questions. The following
example.com 3600 IN 104 "a mx ptr"
example.com 3600 IN 105 "a mx ptr"
is even clearer, since there is no implication that two RRs who happen
to be next to each in type code have anything to do with each other.
Mnemonics like TXTspf1 and TXTspf2 might imply they do.
<snip>
For the vast majority of people, publishing SPF1 records will be all
they need to do or worring about. For those that require different
records for the PRA check vs the MAIL FROM and HELO checks, they can
publish SPF2 records.
This doesn't seem to me an argument *against* making them distinct;
it seems to be an argument that the working group should not have chosen
PRA. Given that it has, making them distinct seems to be pretty much
required.
Speaking without hats,
Ted Hardie