Hi Paul,
> >> "added" really does just mean "added" not "inserted".
> >
> > I don't know what that means. If you add something to an unordered
> > set and then ask for the contents of the set, the order you'll get
> > its contents is undefined.
>
> why do you call a section a "set"?
Because it isn't stated anywhere that they're not just a bag of things
that are added to, and `added' isn't `append'? It may seem pedantic,
but it has helped allow different interpretations to spread over the
years.
> within an rrset, order doesn't matter, because rrsets are "sets".
Agreed, and even RFC 1034, pre-dating RRsets, says
The set of resource information associated with a particular name is
composed of separate resource records (RRs). The order of RRs in a
set is not significant, and need not be preserved by name servers,
resolvers, or other parts of the DNS.
> within a section, one adds to the end, appending rrsets. order should
> probably not matter, but it has mattered for a long time and any
> sender who either scrambles the rr's so that sets are not contiguous
> or places cname rrsets after the targets they point to is going to
> lose.
I agree. Unfortunately, the user is the loser who then has to debug
what's been debugged before by others, followed by trying to get the
server to change in the face of RFCs that allow ENOTABUG. :-)
> > The question, for the purposes of the protocol definition, is
> > whether a message section (or maybe just the answer section) is an
> > ordered set of unordered RRsets. If so, we probably ought to write
> > that down somewhere, and specify the order, because as near as I can
> > see it never has been specified.
>
> i agree, this ought to be written down somewhere.
Good. I came here not knowing if it was stated, seems consensus is it
isn't...
> both the contiguity of rrsets, and their ordering within sections,
> should not have mattered, but now does, due to naive implementors
> (like me-- i'm the author of the code jinmei posted that freebsd link
> to a few hours ago.)
...though there's an obvious order that results from following the RFCs
in the simple way, and that's allowed parsers to make matching
assumptions. AFAICS it *should* be possible to state that order such
that the majority of existing stub resolvers then comply.
Cheers, Ralph.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
