Project

General

Profile

Actions

Feature #4440

closed

Typed name components

Added by Junxiao Shi almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Define NameComponent to permit multiple TLV-TYPE numbers, in addition to existing GenericNameComponent and ImplicitSha256DigestComponent.
Assign TLV-TYPE numbers to existing naming conventions.
Establish a IANA-style registry to assign TLV-TYPE numbers for future naming conventions.

This issue involves protocol updates only. Implementation in forwarder and libraries shall be separate issues.


Related issues 3 (0 open3 closed)

Related to NDN Specifications - Feature #2012: MarkedComponentRejectedAlex Afanasyev

Actions
Related to NDN Specifications - Task #3680: NameComponent of type 19 would conflict with Exclude AnyRejected07/19/2016

Actions
Blocks ndn-cxx - Feature #4526: Recognize typed name componentsClosedJunxiao Shi

Actions
Actions #1

Updated by Junxiao Shi almost 7 years ago

  • Description updated (diff)
Actions #2

Updated by Junxiao Shi almost 7 years ago

Actions #3

Updated by Junxiao Shi almost 7 years ago

  • Related to Task #3680: NameComponent of type 19 would conflict with Exclude Any added
Actions #4

Updated by Anonymous almost 7 years ago

On further thought, I agree that the canonical order of name components can be checked with memcmp of the encoded TLV (since the type is more important than the length).

Actions #5

Updated by Junxiao Shi over 6 years ago

As of https://gerrit.named-data.net/4441 patchset16, memcmp on TLV-VALUE gives correct result of canonical order only if there is no ignored TLV elements within the Name.

Consider lhs=0706 080141 080145 and rhs=070A 080141 FD800000 080142, a memcmp would determine lhs comes before rhs in canonical order.

"NDN Name Format" says:

Valid name component types are in the range 1 - 32767. Name component type 0 is reserved to indicate an invalid name component.

Thus, the second sub-element of rhs FD800000 is not a valid name component because its TLV-TYPE is out of range.

"Considerations for Evolvability of TLV-Based Encoding" says:

At the same time, if decoder encounters an unrecognized or out-of-order element, the behavior should be as follows:
if the least significant bit of element's TLV-TYPE number is 0, ignore the element and continue decoding.

Since TLV-TYPE 0x8000 has LSB 0, this sub-element should be ignored, so rhs is equivalent to 0706 080141 080142. Thus, lhs comes after rhs in canonical order, and memcmp on original lhs and rhs gave wrong result.

Actions #6

Updated by Alex Afanasyev over 6 years ago

There is no such thing for names, as name component TLVs are not interpreted by the router and there is explicit definition in the name what to do if type is not known.

Actions #7

Updated by Davide Pesavento over 6 years ago

  • Status changed from New to In Progress
  • Assignee set to Alex Afanasyev
Actions #8

Updated by Davide Pesavento over 6 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100
Actions #9

Updated by Junxiao Shi over 6 years ago

Actions

Also available in: Atom PDF