[ndnSIM] Content Object IDs

[Junxiao Shi]

Hi John

Here's what I find a little peculiar, for example:
>
>
>    - When I explicitly request content with appended sequence number 750
>    and 1000, I get the following:
>       - 750:   %FE%02%EE
>       - 1000:  %FE%03%E8
>    - When I request content with appended sequence numbers 7,500 and
>    10,000, I get the following:
>       - 7500:  %FE%1DL
>       - 10000: %FE%27%10
>
> Remember that every name component is binary. The string representation,
including % escaping, comes from NDN URI scheme
<https://named-data.net/doc/NDN-TLV/current/name.html#ndn-uri-scheme>.
The above components, written as hexadecimal bytes, are:

FE 02 EE

   - FE: sequence number marker
   <https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>
   - 02 EE: number 0x02EE, or 750 in decimal

FE 03 E8

   - FE: sequence number marker
   <https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>
   - 03 E8: number 0x03E8, or 1000 in decimal

FE 1D 4C

   - FE: sequence number marker
   <https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>
   - 1D 4C: number 0x1D4C, or 7500 in decimal

FE 27 10

   - FE: sequence number marker
   <https://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>
   - 27 10: number 0x2710, or 10000 in decimal



> In the groupings, if we remove the initial %FE%, then we just have
> hexadecimal couplets that do in fact equal the appended sequence numbers, *except
> for *7500, which has this *1DL* 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.
>

String representation is not hexadecimal. It's URI encoding as defined in
RFC3986.


>
> 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.
>
>
Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20171207/39215d95/attachment.html>