<div dir="ltr"><div class="gmail_extra">Dear folks</div><div class="gmail_extra"><br></div><div class="gmail_extra">I agree with @MarkStapp that Naming Conventions rev1 does not guarantee version/segment components to be unambiguous.</div><div class="gmail_extra">One alternate proposal was to use an additional NameComponent before the number as a marker, such as "_v/<version>" "_s/<segment>". This alternate proposal is also unable to make version/segment components unambiguous, and it doesn't work well with ChildSelector.</div><div class="gmail_extra"><br></div><div class="gmail_extra">One easy solution to this problem is: restrict the octets to be used in regular names.</div><div class="gmail_extra">In rev1, we could require regular NameComponent to start with a valid UTF8 character.</div><div class="gmail_extra">In alternate proposal, we could forbid regular NameComponent to start with "_".</div><div class="gmail_extra">However, this solution is undesirable, because some applications do need to operate with binary components (eg. SignatureBits component in signed Interest).</div><div class="gmail_extra"><br></div><div class="gmail_extra">NDN-TLV 0.2.0 (unapproved spec) introduces <a href="http://gerrit.named-data.net/gitweb?p=NDN-TLV.git;a=blob;f=name.rst;h=922bb1cdd568e90bb9e36e8b9339d6c819d2cf06;hb=1ac334640da059791ad5c75637eee075fd0b87b3#l11" target="_blank">NumberComponent </a>to indicate a component is a number.</div><div class="gmail_extra">This is insufficient because it doesn't say the meaning of a number: is it a version number or a segment number?</div><div class="gmail_extra"><br></div><div class="gmail_extra">One solution is to declare many new TLV types: VersionComponent, SegmentComponent, TimestampComponent, etc.</div><div class="gmail_extra">This can guarantee unambiguity, but this restricts the introduction of new convention, because when we want to introduce another convention in the future, old consumer applications would not understand the new TLV type.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If I'm to redesign the convention, I would introduce a MarkedComponent TLV type.</div><div class="gmail_extra">The MarkedComponent TLV can appear in place of NameComponent.<br></div><div class="gmail_extra">The value part of a MarkedComponent contains a VAR-NUMBER which is a marker code, followed by zero or more arbitrary octets.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="courier new, monospace">Name ::= NAME-TYPE TLV-LENGTH (NameComponent | MarkedComponent)*</font></div><div class="gmail_extra"><font face="courier new, monospace">FinalBlockId ::= FINAL-BLOCK-ID-TYPE TLV-LENGTH (NameComponent | MarkedComponent)</font></div><div class="gmail_extra"><font face="courier new, monospace">MarkedComponent ::= MARKED-COMPONENT-TYPE TLV-LENGTH VAR-NUMBER BYTE*</font></div><div class="gmail_extra"><br></div><div class="gmail_extra">The canonical order is defined as:</div><div class="gmail_extra"><ul><li>A MarkedComponent is less than any NameComponent.</li><li>Two MarkedComponents are compared by their length and value, in the same way as NameComponent.</li></ul></div><div class="gmail_extra"><br></div><div class="gmail_extra">The benefits of this solution is:</div><div class="gmail_extra"><ul><li>Version/segment/etc components are distinguished from regular NameComponent, because they have a distinct TLV-TYPE: MarkedComponent.</li><li>Adding a new convention only needs allocation of a marker code. No new TLV type is introduced, so that old consumer can continue to work.</li><li>Encoding marker code as VAR-NUMBER allows much larger marker space than restricting to one-octet marker.</li><li>Canonical order evaluation is efficient. It's unnecessary to compare marker code and BYTE* individually, because most applications won't have different markers under the same prefix.</li></ul></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours, Junxiao</div></div>