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

[Junxiao Shi]

Hi Varun

Both NDN-TLV and CBOR can be considered "standardized" in the context of
NDN applications.
You can choose either one, but you should write down the schema first. In
other words, CBOR is not an excuse for not writing the schema.

To achieve compact encoding in CBOR, you should consider using numeric keys
in maps, which would be more compact than string keys.
Caution: not every CBOR implementation supports every CBOR feature. Thus,
it may end up being more complicated than NDN-TLV.

Sidenode: I've used CBOR in the past. See my name on
https://github.com/PelionIoT/cbor-sync and
https://github.com/bergos/ArduinoCbor .

Yours, Junxiao

On Wed, Jan 20, 2021 at 6:49 AM Varun Patil <varunpatil at ucla.edu> wrote:

> *External Email*
> 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/0e2d3d2a/attachment.html>