Re: field types, was provisioning software, was DNS RRTYPEs, the difficu

> > Doubtful. If a record needs to have, say, a priority field, or a port number,
> > given the existence of MX, SRV, and various other RRs it's going to be very
> > difficult for the designers of said field to argue that that should be done 
> > as
> > ASCII text that has to be parsed out to use.
> Agree with you but too many people today "just" program in perl och python 
> where the parsing is just a cast or similar, and they do not
> understand this argument of yours -- which I once again completely stand 
> behind myself.
Honestly, if new RR types were all text to be parsed by clients, a la
SPF and DKIM, that wouldn't be the worst thing in the world.  The main
advantage of a new RR type is that clients can ask for it specifically
and know that any they answer they get is that kind of data, as opposed
to overloaded TXT where you get what you get.

If the DNS records have binary fields, the parsing happens in the DNS
server.  If they're text, the parsing happens in the client.  Back
when the DNS was young, the suggestion that clients would have to
parse the records would have seemed nuts.  Now mail clients parse
multiple SPF and DKIM records on every mail transaction and nobody
cares.  An advantage of parsing in the server is that you catch syntax
records earlier, but that's still no guarantee that the data are
valid.  (For example, see the MX data for international.com, which
caused a mail loop I fixed yesterday.)  An advantage of parsing in the
client is that the parser is in code managed by people who care about
it, rather than managed by some distant DNS operator.

I suppose that unparsed records mean that the server can't add
additional section records, but based on yesterday's discussion, it
sounds like nobody's using them any more, so who cares?




-- 
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf