NFD » NDN Specifications

TLV-TYPE 0 (zero) is currently unused, can we reserve it to indicate an invalid type that MUST NOT appear on the wire? That way we can keep a 32-bit type as commonly implemented today.

And we can restrict TLV-LENGTH to 32 bits as well (all 32-bit values are valid in this case).

Limiting TLV-LENGTH was discussed at 20190325 call and was rejected.

I don’t see a reason to require [2^31,3^32) range for TLV-TYPE. Having 2³¹ numbers is more than enough.

Junxiao Shi wrote:

Limiting TLV-LENGTH was discussed at 20190325 call and was rejected.

The general idea was NOT rejected. In fact, nobody was opposed to limiting TLV-LENGTH, we just couldn't reach a consensus on what exact range to limit it to.

I don’t see a reason to require [2^31,3^32) range for TLV-TYPE. Having 2³¹ numbers is more than enough.

I could make the same argument for 2³⁰ or 2²⁹ .... It is much more natural to use a power-of-two such as 32. When we decided to use 31 bits I didn't realize that TLV-TYPE 0 is unused. Using 32 bits, with 0 reserved to indicate an invalid TLV, makes a lot more sense now.

There's a suggestion about:

Type code 0 (zero) is reserved to indicate an invalid TLV element and ... should be discarded / treated as ...

I'm reluctant to require receiver to discard any packet with zero at TLV-TYPE position. In fact, my vision is to use zeros as padding bytes when necessary, so that packets can be more efficiently encoded in producers and more efficiently modified by forwarder.

Junxiao Shi wrote:

There's a suggestion

It's not a suggestion. It's a clarification of what has already been decided.

I'm reluctant to require receiver to discard any packet with zero at TLV-TYPE position. In fact, my vision is to use zeros as padding bytes when necessary, so that packets can be more efficiently encoded in producers and more efficiently modified by forwarder.

I'm not following here... what does padding have to do with this? You already cannot send a TLV with type == 0, it would be treated as unrecognized.

The "padding" thing is to have the decoder ignore any 0x00 where a TLV element is ignored, so that encoder can use any length of 0x00 octets as padding.
However, I think whether or not declaring 0x00 as invalid TLV-TYPE does not change whether padding could be added in the future, so I won't pursue this now.