<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>If you wish to maintain the current NDN definition of canonical order, having the T before the L will not work, if the T can have different values.</div>
<div><br>
</div>
<div>How do you do exclusions? Are the not based on canonical order? And prefix matching in general for “left most child” versus “right most child”? That is all affected by the canonical order. You can change the definition of the canonical order to make
these things work, but it will ripple through the stack and forwarder.</div>
<div><br>
</div>
<div>I would also disagree with the statement "because most applications won't have different markers under the same prefix.” What is that based on? Of course you need to match the markers and octet strings. Also, the forwarder has no idea of “the application.”
It has to treat all these things as opaque values, it will be comparing the entire values to determine canonical ordering for content to interest matching.</div>
<div><br>
</div>
<div>Marc</div>
<div><br>
</div>
<br>
<div>
<div>On Sep 15, 2014, at 12:12 PM, Thompson, Jeff <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Marc. You say "if the T comes before the L, then the short-lex ordering does not work" meaning that the ordering will not depend on the length of the name component "value" but on the type. </div>
<div><br>
</div>
<div>It seems Junxiao worried about this too when he said "It's unnecessary to compare marker code and BYTE* individually, because most applications won't have different markers under the same prefix."</div>
<div><br>
</div>
<div>Is there a use case where it matters that short-lex odering is thrown off when comparing two name components with different types? Is it safe to assume that an application will always be doing short-lex comparison of two name components of the same type
(for example, leftmost child of two version components)?</div>
<div><br>
</div>
<div>- Jeff T</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style="font-weight:bold">From: </span>"<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>" <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>><br>
<span style="font-weight:bold">Date: </span>Monday, September 15, 2014 11:50 AM<br>
<span style="font-weight:bold">To: </span>Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>" <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>>, "<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>"
<<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Ndn-interest] any comments on naming convention?<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>On Sep 15, 2014, at 11:33 AM, Thompson, Jeff <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>> wrote:</div>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div style="font-family: Calibri, sans-serif; font-size: 14px;">Hi Mark,</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<div><font face="Calibri,sans-serif">Thanks for the clear summary. You say "</font>it became clear that it is difficult to have a “strcmp()” style comparison over the raw TLV bytes with a variable-length T and L encoding." Can you say more about why varible-length encoding
makes strcmp difficult?</div>
</div>
</blockquote>
<div><br>
</div>
<div>At the time, we were having discussions about is a 2-byte “0” different than a 1-byte “0”, for example. If they are the same meaning, but one is just incorrectly encoded in 2-bytes, then do we have to validate each T and throw away the ones that are mis-encoded?</div>
<div><br>
</div>
<div>Also, if the T comes before the L, then the short-lex ordering does not work. Short-lex says that name component A is less than B if then length of A is less than B or of |A| = |B| and A sorts before B. If the T comes before the L, then you cannot simply
do a strcmp() because the variable length T’s will throw things off. All you can say is that within a T value, you use short-lex.</div>
<div><br>
</div>
<div>Marc</div>
<br>
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div></div>
<div>- Jeff T</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; font-size: 14px; ">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style="font-weight:bold">From: </span>"<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>" <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>><br>
<span style="font-weight:bold">Date: </span>Monday, September 15, 2014 11:20 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>" <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Ndn-interest] any comments on naming convention?<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
This is an interesting discussion. At PARC, when we went away from ccnb to TLV-based name components, we agreed with the Cisco position that different types of name components should have different TLV types.
<div><br>
</div>
<div>Anything that used to be a command marker was moved to a TLV type and we no longer use command markers. We see having TLV types in the name as redundant with command markers, so long as there is a type space for applications to use to generate their own
application-dependent types.</div>
<div><br>
</div>
<div>We use one general name (binary) name component, one for versions, one for segments (chunks), one for nonces (in the name, not an Interest nonce), one for keys. In our re-implementation of the 0.x repo protocol, those repo command-markers became their
own application-dependent name TLV types. In our sync protocol, we use other application-dependent TLV types instead of command markers.</div>
<div><br>
</div>
<div>Our ordering is defined as the lexicographic compare of each TLV, including the T and L. Because we use a fixed type and fixed length value, this ordering is always well-defined. About a year ago, when we were considering different variable length TLV
schemes, it became clear that it is difficult to have a “strcmp()” style comparison over the raw TLV bytes with a variable-length T and L encoding. There are some T and L encoding schemes that still allow comparison over the raw bytes, but they have their
own drawbacks.</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
</blockquote>
</div>
<div><br>
</div>
<div>I would disagree with this statement. Anytime you introduce a new command-marker, old applications will not understand it. If the new command-marker is required for application execution, then all applications must be updated. If the new command-marker
(or tlv type) is not required, then the old application should continue just fine treating the type as opaque.</div>
<div><br>
</div>
<div>Marc Mosko<br>
<div><br>
</div>
<div><br>
<div>
<div>On Sep 15, 2014, at 10:49 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<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>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</span></div>
</blockquote>
</div>
<br>
</body>
</html>