<div dir="ltr">Junxiao,<div><br></div><div>Thank you so much for your information. I read through the RFC (most of the 61 pages) to get a more solid idea, and of course the NDN URI Scheme page. With my utmost respect to the incredible community, I definitely think the documentation for the NDN URI Scheme needs to perhaps be enhanced with more information and examples (e.g., what different components might mean, etc.) That would greatly enhance the usability of the information on that page.</div><div><br></div><div>Secondly, I took your advice and took a step back and revisited alternatives to trying to parse the URI, and instead am doing this now:</div><div><br></div><div><b>For the sake of posterity regarding this topic</b>, I present some findings below:</div><div><font face="monospace, monospace" size="4"><br></font></div><div><font face="monospace, monospace" size="4"><b>(Given someName is a Name object pointer)</b></font></div><div><font face="monospace, monospace" size="4"><b><br></b></font></div><div><font face="monospace, monospace" size="4"><b>//------> To make sure something is sequence number</b></font></div><div><font face="monospace, monospace" size="4"><b>if(someName->at(1).isSequenceNumber()) </b></font></div><div><font face="monospace, monospace" size="4"><b>{<br> //do something<br>}</b></font></div><div><font face="monospace, monospace" size="4"><b><br></b></font></div><div><b style="font-family:monospace,monospace;font-size:large">//------></b><font face="monospace, monospace" size="4"><b> To access sequence number as a number (specificaly as a uint64_t, that is, a 64-bit fixed-width unsigned integer)</b></font></div><div><font face="monospace, monospace" size="4"><b>someName->at(1).toSequenceNumber()</b></font></div><div><br></div><div><br></div><div><br></div><div>Thanks again for your help! I might have spent many more days working on this had you not helped me see the format wasn't quite what it would seem.</div><div><br></div><div>Cheers!</div><div><br></div><div>John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 12:29 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi John<div><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Here's what I find a little peculiar, for example:</div><div><br></div><div><ul><li>When I explicitly request content with appended sequence number 750 and 1000, I get the following:</li><ul><li>750: %FE%02%EE</li><li>1000: %FE%03%E8</li></ul><li>When I request content with appended sequence numbers 7,500 and 10,000, I get the following:</li><ul><li>7500: %FE%1DL</li><li>10000: %FE%27%10</li></ul></ul></div></div></blockquote></span><div>Remember that every name component is binary. The string representation, including % escaping, comes from <a href="https://named-data.net/doc/NDN-TLV/current/name.html#ndn-uri-scheme" target="_blank">NDN URI scheme</a>.</div><div>The above components, written as hexadecimal bytes, are:</div><div><br></div><div>FE 02 EE</div><div><ul><li>FE: sequence number <a href="https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/" target="_blank">marker</a></li><li>02 EE: number 0x02EE, or 750 in decimal</li></ul></div><div><div>FE 03 E8</div><div><ul><li>FE: sequence number <a href="https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/" target="_blank">marker</a></li><li>03 E8: number 0x03E8, or 1000 in decimal</li></ul></div></div><div><div>FE 1D 4C</div><div><ul><li>FE: sequence number <a href="https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/" target="_blank">marker</a></li><li>1D 4C: number 0x1D4C, or 7500 in decimal</li></ul></div></div><div><div>FE 27 10</div><div><ul><li>FE: sequence number <a href="https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/" target="_blank">marker</a></li><li>27 10: number 0x2710, or 10000 in decimal</li></ul></div></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div></div><div>In the groupings, if we remove the initial %FE%, then we just have hexadecimal couplets that do in fact equal the appended sequence numbers, <b>except for </b>7500, which has this <b>1DL</b> at the end... I have no idea where this is coming from. How is 1DL even a value? You mentioned it was "binary", but I'm not 100% sure what you mean in this context - I assumed that the string representations are the hexadecimal values representing the binary, which makes sense for many of the values. all the low numbers work fine - 10 --> 0A, 11 --> 0B, etc. And some of the large numbers work. But some simply don't.</div></div></blockquote><div><br></div></span><div>String representation is not hexadecimal. It's URI encoding as defined in RFC3986.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>It seemed so straightforward and logical, except I'm finding certain values are not being translated correctly. I'm digging deeper into the appending that I do, but this is what it appears.</div><div><br></div></div></blockquote><div> </div></span><div>Yours, Junxiao </div></div></div></div></div>
</blockquote></div><br></div>