Hi Mark, > > > 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. > > RFC 1034 says to add to the answer. Not added to a list that will > then be compiled into a answer with possible reordering once all the > records have been collected. OO programing has a lot to answer for > here.
Isn't this old ground? Yes, the RFC can be read with, to me, the "obvious" interpretation that answers are appended. But "add" is not "append". And it's nothing to do with OO, which I dislike. Just imprecise language that has allowed variation in implementations over time. I don't suppose the RFC would be written that imprecisely today because their quality has improved in the light of experience of (mis)interpretation. > RFC 1034, 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A show a CNAME response > > +---------------------------------------------------+ > Header | OPCODE=SQUERY, RESPONSE, AA | > +---------------------------------------------------+ > Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | > +---------------------------------------------------+ > Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | > | C.ISI.EDU. 86400 IN A 10.0.0.52 | > +---------------------------------------------------+ > Authority | <empty> | > +---------------------------------------------------+ > Additional | <empty> | > +---------------------------------------------------+ Yes, but it's not the only possible one from a wider, not ruled out, interpretation that exists in practice. I'm not arguing for a change in the vast majority of software, but a clarification that will make their assumptions, given the add != append interpretation, valid. It will also give future implementations more guidance, and allow bug reports to have something concrete to reference. What's the downside? Cheers, Ralph. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
