<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dick,<div class=""><br class=""></div><div class="">Let me pose this question: This field of the SOA record is informational, and often (in the real world) doesn't lead to an actual functioning email address. When dealing with DNS records, how often does a script actually need this value in email address format? Compare that with the frequency of needing this in DNS domain name format, the way it is represented in DNS messages. I believe you will find that the latter need is far more prevalent than the former.</div><div class=""><br class=""></div><div class="">Now consider that you are doing extra work to decode this value, which is basically never needed, and then asking the script writer to do extra work to convert it back again. As you said, it's an inconsequential amount of work in terms of execution time (though not inconsequential in terms of coding time), but given how infrequently anyone actually cares about the semantic meaning of this field, vs. simply wanting to accurately record the fields of an SOA record, it seems counterintuitive that the module would behave this way.</div><div class=""><br class=""></div><div class="">And of course, there is the matter that it used to behave differently. My scripts broke in the 0.69 update. That bothered me. I rewrote them to stop using the (IMO broken) new behavior, and now use the SOA object's string method followed by 'split' to obtain the fields in DNS format.</div><div class=""><br class=""></div><div class="">I don't understand why this matters to you so much. There's an easy conversion routine, so rather than break the API, it would have been better to simply advertise that you have a handy conversion routine available for those who want to work with the data in email address format. At this point, obviously, you risk breaking scripts either way, because you've allowed the situation to remain for so long, but I think it's pretty clear the change in 0.69 was a mistake.</div><div class=""><br class=""></div><div class="">That's my opinion. I'll get off my soapbox now.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Chris Buxton</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 21, 2015, at 11:48 AM, Dick Franks <<a href="mailto:rwfranks@acm.org" class="">rwfranks@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div class=""><div dir="ltr" class=""><span class=""></span></div></div></div>
<br class=""><div class="gmail_quote">On 19 May 2015 at 09:38, Doug Barton <span dir="ltr" class=""><<a href="mailto:dougb@dougbarton.us" target="_blank" class="">dougb@dougbarton.us</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 5/18/15 5:30 PM, Dick Franks wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
All of this was discussed at length on this list in 2012/2013<br class="">
</blockquote>
<br class=""></span>
Yes, and some of us told you at the time that while your reasoning was air tight, and self-consistent; the resulting change did not meet our needs.<br class=""></blockquote><div class=""></div><div class=""><br class=""></div><div class="">The air tight and self-consistent reasoning was founded on a careful analysis of RFC1035. The present implementation of Net::DNS got where it got by following that reasoning. Analysis and air tight reasoning are investments with a long-term yield in the form of design stability.<br class=""><br class=""></div><div class="">The pre-0.69 implementation was not based on a sound analysis of RFC1035, which is regrettable but these things happen. This is the only flaw in Michael Fuhr's original vision.<br class=""><br class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, the obvious, glaring exception to your statement that "There is absolutely nothing useful you can do with the wire-format domain name representation" is that you can, and often need to, stuff it into a data store that will be used by something other than Net::DNS to generate zone files down the road.<br class=""></blockquote><div class=""><br class=""></div><div class="">It is certainly arguable that RFC1035 was wrong in not using RFC822 for the SOA RNAME field in zone file format. This is a mistake we all have to live with. The need to jump through hoops to convert mail addresses into domain names is a direct consequence of that mistake. The need to do so arises from *your* design decision about what to stuff in *your* data store.<br class=""></div><div class=""><br class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So while it makes perfect sense to have a way to generate 822 format from Net::DNS, and it might even make sense to have that be the default,</blockquote><div class=""><br class=""></div><div class="">RFC822 format is the primary representation of entities that claim to be a mail address. The wire-format and domain name representations are encodings of that primary representation.<br class=""></div><div class=""><br class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> it ALSO makes sense to have a way to get the wire format without having to jump through insane hoops to do so.<br class="">
... and just to save you time, no, it does not make sense for Net::DNS to decode the wire format, then have the other system re-encode it.</blockquote><div class=""><br class=""></div><div class="">We will have to agree to differ about what does, or does not, make sense.<br class=""><br class=""></div><div class="">The conversion can be done in a single line. The computational cost is insignificant compared with the cost of resolving the SOA record.<br class=""><br class="">use Net::DNS::Mailbox;<br class=""><br class="">my $email = '<a href="mailto:John.Doe@example.com" target="_blank" class="">John.Doe@example.com</a>';<br class=""><br class="">my $name = new Net::DNS::Mailbox($email)->string; # zone file format<br class=""><br class=""></div><div class=""><br class="">The attractions of doing things this way are:<br class=""></div><div class="">1) The conversion will forever remain in sync with current understanding of RFC1035 and RFC822 et seq.<br class=""></div><div class="">2) If you discover any example which violates the RFCs, I agree to let you kick me until it is fixed.<br class=""></div><div class="">3) The conversion accepts both RFC822 and the domain name encoded format, so there is no need to check which you have.<br class=""></div><div class=""><br class=""><br class=""></div><div class="">-- Dick<br class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">net-dns-users mailing list<br class=""><a href="mailto:net-dns-users@nlnetlabs.nl" class="">net-dns-users@nlnetlabs.nl</a><br class="">https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users</div></blockquote></div><br class=""></div></body></html>