[Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component

[Ignacio.Solis at parc.com]

On 10/10/14, 7:08 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

>> 
>> You still need a name, otherwise the Interest would not have been
>> forwarded.
>> 
>> Also, I¹m not sure where you would get a hash only.  If you did get the
>> hash (and some potentially uninformative name) from the manifest, then
>>you
>> already have that info, it¹s in the manifest.
>
>Yes, manifest can have such information, which in such a hypothetical
>case would need to be remembered somewhere.  However, I think it is
>important to keep all relevant information in the Name, so it can be (to
>some extent) used on its own (less things to remember in the app/library).

I understand that you want to make things simple, but I¹m not sure I see a
big difference here.

What I hear you say is that in the ³keep all relevant information in the
name² method you will keep only that name as state and in the other you
need to keep a manifest.  So, in the state-in-name you would keep
"/foo/bar/version=10/chunk=100² as the context for the stack. This would
allow you to predict that the next content is
"/foo/bar/version=10/chunk=101².  Is this right?

In the manifest method you would need the whole manifest with a list of
the names and hashes.

However, for the state-in-name method, where did you get the hash from?
(We were talking about names with implicit hashes).  Even if you got the
first hash from a link, where did you get the second hash from?   I¹m
assuming you need to keep these hashes somewhere.  And the hashes have to
be associated with names.   Are these hashes not kept in the app/library?
 For us, this structure is basically the manifest.

Nacho



--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com