<div><div dir="auto">Hi Christian</div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The new spec is indeed interesting, one already feels that this will<br>
lead to leaner code!</blockquote><div dir="auto">It’s leaner <i>forwarder</i> code. The case could be different in <i>application</i> side.</div><div dir="auto">For example: <a href="https://redmine.named-data.net/issues/4396">https://redmine.named-data.net/issues/4396</a></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wonder about the terminology of "prefix name, exact name and full<br>
name", whether a semantic denotation instead one based on the match<br>
mechanics would have been easier to understand, and simpler.<br>
<br>
One could have used:<br>
- name :== forwarding hint with an optional digest<br>
- forwarding hint :== one or more name component<br>
- digest :== sha256 value</blockquote><div dir="auto"><br></div><div dir="auto">The current goal is to clearly explain the semantics, not to use the most concise EBNF. It would be confusing if Name is built upon forwarding hint.</div><div dir="auto">At EBNF level, this definition is wrong. First, ImplicitSha256DigestComponent <i>is-a</i> NameComponent, so your “forwarding hint” can still contain a digest. Second, the actual ForwardingHint is a sequence of Delegations.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because prefix name and exact name are the same, and nothing more than<br>
this: a forwarding hint where one OR MORE data object may satisfy such<br>
an name.</blockquote><div dir="auto">A name is not a forwarding hint. The “forwarding hint” directs Interest to a certain network region. Its delegation is not a prefix of Data name. Please read “Link object” section and Alex’s dissertation <a href="https://irl.cs.ucla.edu/data/files/theses/afanasyev-thesis.pdf">https://irl.cs.ucla.edu/data/files/theses/afanasyev-thesis.pdf</a> for more information.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Of course there is the additional requirement that the name<br>
components must match (prefixly or exactly) those in the data object.<br>
But this is now captured in the "canBePrefix" element, right?<br>
<br>
The definition above, with only one sort of names instead of three,<br>
would be usable for "nameless objects" (which are not captured in spec<br>
0.3) where there are no name components to match, only the digest. I<br>
understand that this would also imply a change in the matching logic,<br>
for example a rule saying that the digest always trumps.</blockquote><div dir="auto">Nameless objects are always possible. Interest name must have at least one component, which could be an ImplicitSha256DigestComponent. Data name has zero component, and the forwarder could use this Data to satisfy an Interest with the Data’s digest.</div><div dir="auto">However, due to lack of hierarchical components in the Interest name, Interest forwarding has to rely on flooding or a hierarchical name in forwarding hint. It is also prohibitively expensive for every forwarder to compute Data digest to find which Interest it could match.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS: Perhaps an overlooked reference to selectors, to be cleaned up? In the Name section:<br>
   ", either as the last component of Interest Name to request<br>
    a specific Data packet, or in the Exclude selector to exclude<br>
    specific Data packet(s)"</blockquote><div dir="auto">Recorded as <a href="https://redmine.named-data.net/issues/4444#note-3">https://redmine.named-data.net/issues/4444#note-3</a></div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div></div></div>