[Ndn-interest] [EXT] Custom TLV vs library
varunpatil at ucla.edu
Wed Jan 20 03:48:42 PST 2021
Thanks for the (very insightful) reply.
If I understand correctly, both reasons to choose NDN-TLV have to do with
not adding a dependency.
My argument for CBOR is similar to the reason we use JSON over arbitrary
formats - a highly standardised encoding will give better results in the
But on the other hand it introduces inconsistency, so I will stick with
NDN-TLV unless there is more encouragement from the community that we want
to try out a new standard.
Any other thoughts?
On Wed, Jan 20, 2021, 12:31 AM Junxiao Shi <shijunxiao at email.arizona.edu>
> Hi Varun
> There is no fundamental difference between NDN-TLV and CBOR.
> In either case, you would need to define a clear and unambiguous schema on
> how each object is encoded.
> NDNts has already implemented PSync and syncps
> <https://ndnts-docs.ndn.today/typedoc/modules/sync.html>, and will
> implement SVS once your protocol is reasonably stable.
> Reasons for choosing CBOR
> CBOR have a machine readable schema language (CDDL, RFC8610
> NDN-TLV only has ABNF schema definition, and this definition often depends
> on comments to express semantics.
> Reasons for choosing NDN-TLV
> General purpose NDN-TLV encoder and decoder are available in most
> CBOR would be an additional dependency, which increases code size,
> especially for webapps and microcontrollers.
> If you need to encode NDN elements, such as a name or a certificate, it is
> natural to embed NDN-TLV inside NDN-TLV.
> It has been argued
> <https://zjkmxy.github.io/posts/2020/07/tlv-reflection/>that NDN-TLV
> codec should use the "reflection" feature, if available in the programming
> python-ndn has an implementation of this idea. Additional experiments
> <https://github.com/zjkmxy/ndn-encoding-test>are being done for Go.
> This would make programming with NDN-TLV easier.
> Yours, Junxiao
> On Mon, Jan 18, 2021 at 11:11 AM Varun Patil <varunpatil at ucla.edu> wrote:
>> *External Email*
>> I've been developing a StateVectorSync library (named-data/ndn-svs), and
>> there seem to be two approaches to encoding the state vector:
>> 1. An NDN custom TLV.
>> 2. A standardised serializer. Currently the library uses
>> boost-serialization, but I'm in favor of CBOR (RFC 8949, Standards Track,
>> Dec. 2020). This would make it easier to write compatible SVS libraries in
>> other languages, since CBOR decoders are already available in virtually
>> every language (also it may be more space efficient than custom TLV blocks).
>> Any thoughts/suggestions on which is the better approach?
>> Varun Patil
>> Graduate Student
>> Computer Science, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest