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

[Varun Patil]

> Both NDN-TLV and CBOR can be considered "standardized" in the context of
> NDN applications.
>
Hmm, alright.


> 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.
>
At least for my use case, there isn't a schema - I just need to encode an
unordered_map<string, int>. Which is why CBOR seemed ideal.


> Caution: not every CBOR implementation supports every CBOR feature. Thus,
> it may end up being more complicated than NDN-TLV.
>
Ah didn't consider this. I guess NDN-TLV seems like a more consistent
solution to go with then.

Thanks again.

Best,
Varun


> 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/20210121/61b9c15d/attachment-0001.html>