Feature #4440
closedTyped name components
100%
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.
Updated by Junxiao Shi almost 7 years ago
- Related to Feature #2012: MarkedComponent added
Updated by Junxiao Shi almost 7 years ago
- Related to Task #3680: NameComponent of type 19 would conflict with Exclude Any added
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).
Updated by Junxiao Shi almost 7 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 type0
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 is0
, 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.
Updated by Alex Afanasyev almost 7 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.
Updated by Davide Pesavento almost 7 years ago
- Status changed from New to In Progress
- Assignee set to Alex Afanasyev
Updated by Davide Pesavento over 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Updated by Junxiao Shi over 6 years ago
- Blocks Feature #4526: Recognize typed name components added