NFD » NDN Specifications

This Task is approved at 20140929 conference call.

A few points are mentioned during the call:

• The motivation of introducing ImplicitSha256DigestComponent for correctness, not for performance. A Name is a full Name of a Data packet only if it ends with an ImplicitSha256DigestComponent.
• Although it's possible to encode the implicit digest as a MarkedComponent (#2012), using a specific type is better because forwarding plane needs to understand implicit digest, but need not understand MarkedComponent.
• A Name with ImplicitSha256DigestComponent can only appear in Interest packet, and it must be the last component.
• ImplicitSha256DigestComponent can also appear in Exclude element.
• In canonical ordering, ImplicitSha256DigestComponent is defined to be less than NameComponent, so that Interest "/A" ChildSelector=leftmost could pick Data "/A/<digest>" instead of Data "/A/1/<digest>".

You would not need a flag day. If/when necessary, we can redefine full name of the Data to contain either current sha256 digest or some new digest. This way, during the transition period the requesters will be able to use either and after the transition period this dual name of the Data packets will be removed.

during the transition period the requesters will be able to use either and after the transition period this dual name of the Data packets will be removed.

This means during the transition period, a Data packet will have two full Names. Is this bad?