[ndnSIM] Content Object IDs

John Baugh jpbaugh at umich.edu
Fri Dec 8 22:07:40 PST 2017


Junxiao,

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.

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:

*For the sake of posterity regarding this topic*, I present some findings
below:

*(Given someName is a Name object pointer)*

*//------> To make sure something is sequence number*
*if(someName->at(1).isSequenceNumber()) *


*{   //do something}*

*//------>** To access sequence number as a number (specificaly as a
uint64_t, that is, a 64-bit fixed-width unsigned integer)*
*someName->at(1).toSequenceNumber()*



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.

Cheers!

John

On Thu, Dec 7, 2017 at 12:29 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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/20171209/599b9ed6/attachment-0001.html>


More information about the ndnSIM mailing list