this is "selling past the close", an error we are all here oft guilty
of, but here i go anyway:
Andrew Sullivan wrote:
> IMO There is just an ambiguity in the RFCs, and I think it should be
> fixed.
yes. fundamentally, rrset ordering within answer sections needs
clarification. noone disagrees.
> I understand that you think it's clear (and even why you do),
> but I think your understanding stems from what you think is the
> natural way to implement that specification.
i disagree. i do not think that you understand why mark and i both think
it's clear. all DNS implementations for the three years before RFC 882
was published until ten years after RFC 1034 was published worked this
way. even the ones written in LISP worked this way, and i think the data
structures and philosophy of LISP would have made set-like behaviour
very easy to do, if there was any reason to consider doing it that way.
there was no such reason, as i'll explain.
it's rare to quote from an obsolete RFC, but since it's highly
illuminative here, i will:
[RFC 883, Page 12, Query and response transport]
Hence datagram messages are limited to 512 octets. If a
datagram message would exceed 512 octets, it is truncated
and a truncation flag is set in its header.
[ibid, Page 27, Header section format]
TC - TrunCation - specifies that this message was truncated
due to length greater than 512 characters.
This bit is valid in datagram messages but not
in messages sent over virtual circuits.
[ibid, page 51, RESOLVER ALGORYTHMS]
... The resolver may also find that a datagram reply was
truncated, and open a virtual circuit so that the complete reply
can be recovered.
none of these descriptions of truncation, nor indeed the truncation
descriptions in later RFCs, make any sense if "add" doesn't mean "to the
end of the response you are constructing". in order to impute ambiguity
about what "add" might have meant, these RFCs would have had to contain
text giving relative priorities for each possible datum in the message,
so that when truncation occurred there would be some idea of how to
construct the truncated message.
furthermore, the algorithms describing what to "add" are given in
section order. that is, everything you need to know when constructing
the authority section is present in the answer section, and everything
you need to know when constructing the additional section is present in
the answer and authority sections.
this doesn't matter. the document is unclear and requires clarification.
however, until that occurs, there is ample support in context for "add"
meaning "to the end". in fact, there's ample support in the existing
unclear document for "add" meaning "to the end of the message" rather
than "to the end of the section".
> ... If you had different
> background or other things were more natual to you, you might come to
> a different conclusion.
no. honestly, no background that included implementing DNS between 1980
and 1995 could lead to any different conclusion, and nor did it so lead.
> ... And if you think it's perfectly clear,
> anyway, what is your possible objection to someone writing down the
> clarification you don't need?
noone is objecting to clarifying it. the objection is to saying it's
ambiguous as written. it's absolutely unambiguous. it's also unclear.
> ... Especially when it's someone who hasn't
> historically participated a lot here and who appears to be offering to
> do free work?
bring that on, by all means.
--
Paul Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
