NFD » NDN Specifications

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).

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.

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.