<div dir="ltr">Hi Jeff<div><br></div><div>DNS resolution is simply not the responsibility of NFD. Management utility (nfdc) should take care of that.</div><div>After completing the resolution process, a canonical FaceUri is generated and passed to NFD for face creation (and face query).</div><div><br></div><div>I'm not assuming anything about how NFD is used in the community.<br></div><div>The first message in this thread is an announcement that all users must change their programs if they are using this specific feature.</div><div><br></div><div><br></div><div><div>Face query operation requires exact match of FaceUri. That's why NFD expects a canonical FaceUri that remains the same for the same endpoint. Allowing any alias of a canonical FaceUri would cause problems in face query operation.</div><div><br></div></div><div>The usage of udp4, udp6, tcp4, tcp6 doesn't require IANA registration, because FaceUri is not in the same namespace as URI.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 1, 2014 at 9:00 AM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Junxiao,</div><span>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<p>Hi Jeff</p>
<p>DNS is a complex affair that has many details to take care of.</p>
</blockquote>
</span>
</span><div>I don't understand exactly what's complex for NFD here;  is it the asynchronous nature of the resolution process that you prefer not be handled in the daemon?    </div><span>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<p><br>
NFD isn't the right place to perform DNS resolution, so we have decided to off-load this operation to the client library.<br>
ndn-cxx provides FaceUri::isCanonical method that determines whether a FaceUri is canonical.<br>
ndn-cxx provides FaceUri::canonize method to perform DNS resolution, and obtain a canonical FaceUri.</p>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<p>Most users shouldn't be affected, because nfdc command line tool will canonize FaceUri before creating face.</p>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<p><br>
NLSR is the only known app that uses faces/create command through ndn-cxx Controller API, and NLSR has been updated</p>
</blockquote>
</span>
</span><div>I'm not sure that it's good practice to assume you know the cases in which the library and daemon are being used in the research community.  </div><span>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<p><br>
Apps based on ndn-ccl shouldn't be affected because ndn-ccl API doesn't have a face creation method.</p>
<p>udp and udp4 are not equivalent. udp can be resolved to either udp4 or udp6.<br>
udp://<a href="http://192.0.2.1" target="_blank">192.0.2.1</a> will be canonized as udp4://<a href="http://192.0.2.1:6363" target="_blank">192.0.2.1:6363</a></p>
</blockquote>
</span>
</span><div>Yes, all I was getting at is that the convention could be similarly defined at the NFD level.  </div>
<div><br>
</div>
<div>Is the use of udp and tcp in URI schemes, rather than, say, ndnudp or ndntcp going to cause any conflicts with registered URI schemes in  the future? <a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml" target="_blank">http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml</a> </div><span><font color="#888888">
<div><br>
</div>
<div>Jeff</div></font></span></div></blockquote></div></div></div></div>