<div dir="ltr"><div class="gmail_quote"><div>Hi Junxiao, </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Even if it's an unordered_map<string, int>, you still need to write a schema.</div><div>The schema would answer questions like:</div><div><ul><li>Is the string a byte string (major type 2) or a text string (major type 3)?</li><li>Is it allowable to encode the integer as bignum format?<br></li></ul></div></div></div></blockquote><div>Ah, I see what you mean. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>If you are referring to the <a href="https://github.com/JonnyKong/Sync-MANET/blob/388d41f5e5b2626f9d82a06ad7d41c97e490ba5a/svs_helper.hpp#L12-L29" target="_blank">version vector</a>:</div><div><ul><li>It's more than an unordered_map<string, int>. There are three items in each tuple.</li></ul></div></div></div></blockquote><div>Oh my implementation doesn't have the preference flag yet.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><ul><li>It should not be "unordered" because allowing arbitrary order would cause different network nodes to encode this component differently, reducing the effectiveness of Interest aggregation.</li></ul></div></div></div></blockquote><div>Good point. Thanks for pointing this out. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><ul><li>If the string is actually a name, you should use its NDN-TLV encoding, not the URI format. Canonical URI is standardized but less compact. Alternate URI is implementation dependent - PSync made the mistake of using alternate URI, so it's not portable.<br></li></ul></div></div></div></blockquote><div>Yup, not using URIs anywhere. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Version vector encoded in NDN-TLV would be something like:</div><div style="margin-left:40px"><span style="font-family:monospace">VERSION-VECTOR = *VECTOR-VECTOR-ITEM<br>; items should be sorted by Name in NDN canonical order<br><br>VERSION-VECTOR-ITEM = VERSION-VECTOR-ITEM-TYPE TLV-LENGTH<br>                      Name<br>                      SeqNum<br>                      [IsImportant]<br><br>SeqNum = SequenceNumNameComponent<br><br>IsImportant = IS-IMPORTANT-TYPE<br>              TLV-LENGTH ; zero<br><br>VERSION-VECTOR-ITEM-TYPE = 0xFD.2F.C1<br><br>IS-IMPORTANT-TYPE = 0xFD.2F.C3<br><br>; Name defined in NDN Packet Format v0.3<br>; SequenceNumNameComponent is defined in NDN Naming Conventions rev02</span><br></div><span style="font-family:monospace"></span><div><br></div><div>Version vector encoded in CBOR would be something like:<br></div><div style="margin-left:40px"><span style="font-family:monospace">version-vector = {<br>  *name => version-vector-value<br>}<br><br>name = bstr ; Name TLV-VALUE, as defined in NDN Packet Format<br></span></div><div style="margin-left:40px"><span style="font-family:monospace"><br>version-vector-value = [<br>  uint, ; sequence number<br>  bool, ; is important<br>]</span><br></div><div>Map item ordering should follow RFC8949 section 4.2, which differs from NDN canonical order.<br></div><div>Also note that the name is encoded as TLV-VALUE only, because the "NAME-TYPE TLV-LENGTH" portion is redundant. As mentioned above, you should not use the URI format.<br></div></div></div></blockquote><div><br></div><div>Thanks again! Going ahead with the NDN-TLV implementation.</div><div> </div><div>Best,</div><div>Varun</div></div></div>