[Ndn-interest] [EXT] Custom TLV vs library

[Varun Patil]

Hi Junxiao,

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
long term.
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?

Thanks,

Varun

On Wed, Jan 20, 2021, 12:31 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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
> <https://tools.ietf.org/html/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
> libraries.
> 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
> language.
> 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*
>> Hello,
>>
>> 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?
>>
>> Thanks,
>>
>> Varun Patil
>> Graduate Student
>> Computer Science, UCLA
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20210120/9fe216bc/attachment.html>