On 03/Mar/12 18:43, John Levine wrote: > > 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. Well, since that's what is currently being done, it must obviously be feasible. However, there is no reason to stick to it if a better choice is available. > 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. Yes, possibly better than using _prefixes. > 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. Allowing a binary form is also an advantage, although I agree that the hype on performance is a relic. > 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 see a tendency to stick to good parsing models, both by referencing their specs in newer specs and by reusing library function. Except for possible bugs, whose patches could be promptly broadcasted as security fixes, we gathered enough experience with those formats that I think we're likely to get a generic spec right on the first attempt. Public keys, IP addresses, flags, are all candidates for binary field formats. The binary version of "tag=value" could look much like DER, except that tag enumerations could be drawn from the relevant protocol registry. I guess there's plenty of possibilities better than XML. > 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? You mean that a response to a query for, say, DKIM could come with a few byte worth of ADSP added as a bonus, if it fits within the response size? This feature is also missing from draft-levine-dnsextlang-02. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf