<div dir="ltr"><div class="gmail_extra"><div><div><div dir="ltr"><span></span></div></div></div>
<br><div class="gmail_quote">On 19 May 2015 at 09:38, Doug Barton <span dir="ltr"><<a href="mailto:dougb@dougbarton.us" target="_blank">dougb@dougbarton.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 5/18/15 5:30 PM, Dick Franks wrote:<br>
<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>
</blockquote>
<br></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></blockquote><div></div><div><br></div><div>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><br></div><div>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><br><br></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></blockquote><div><br></div><div>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></div><div><br><br></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><br></div><div>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></div><div><br><br></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>

... 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><br></div><div>We will have to agree to differ about what does, or does not, make sense.<br><br></div><div>The conversion can be done in a single line.  The computational cost is insignificant compared with the cost of resolving the SOA record.<br><br>use Net::DNS::Mailbox;<br><br>my $email = '<a href="mailto:John.Doe@example.com" target="_blank">John.Doe@example.com</a>';<br><br>my $name = new Net::DNS::Mailbox($email)->string;  # zone file format<br><br></div><div><br>The attractions of doing things this way are:<br></div><div>1) The conversion will forever remain in sync with current understanding of RFC1035 and RFC822 et seq.<br></div><div>2) If you discover any example which violates the RFCs, I agree to let you kick me until it is fixed.<br></div><div>3) The conversion accepts both RFC822 and the domain name encoded format, so there is no need to check which you have.<br></div><div><br><br></div><div>-- Dick<br><br></div></div></div></div>