NFD » ndn-cxx

My objection to #2021 was partially based on the fact that it's a change to the TLV structure. An application that accidentally pulls one of the experimental Data packets will get a parse error (i.e. exception thrown by the library it uses) if its library isn't aware of the experimental change. This is a serious problem because the app/library will drop the Data packet without telling the application what the "bad" packet was. In other words, the application is in a position where it doesn't know how to avoid the "bad" packet (it was never told its name or implicit digest) and so the only thing it can do is re-request...which will likely just bring the "bad" packet in again. We should probably discuss this problem and potential solutions as a separate topic though (e.g. provide the "bad" packet's digest to the app via a callback).

I don't think there's any such problem here. It sounds like the proposal is to add a new content type value without changing the TLV structure. The only problem would be if parsers enforce acceptable content type values.