[Ndn-interest] any comments on naming convention?

[Marc.Mosko at parc.com]

All of our protocol specs are at http://www.ccnx.org/documentation/.  You need to click on the black bar that says “CCNx 1.0 PROTOCOL SPECIFICATION” to expand it.

This document specifies the overall TLV format
http://www.ccnx.org/pubs/ccnx-mosko-tlvpackets-01.txt

This document specifies how we use our TLV format for CCNx messages and includes the definitions of the common name component types.
http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.txt

In Labeled Segment URIs, we describe a standard URI format for representing URIs with labels for each path segment.
http://www.ccnx.org/pubs/ccnx-mosko-labeledsegments-01.txt

In Labeled Content Information, we describe the new CCNx 1.0 URI scheme “lci:”
http://www.ccnx.org/pubs/ccnx-mosko-labeledcontent-01.txt

In some of the other standards, you may find we introduce other TLV types for name components, as needed in those specifications (note: there’s an error in a couple that assigned over-lapping numbers which we will be fixing soon).

Marc

On Sep 15, 2014, at 1:56 PM, Tai-Lin Chu <tailinchu at gmail.com> wrote:

> @Marc,
> Do you mind giving a link to parc's tlv definition so that people will
> know the exact difference?
> 
> Thanks.
> 
> On Mon, Sep 15, 2014 at 12:23 PM,  <Marc.Mosko at parc.com> wrote:
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Marc
>> 
>> 
>> On Sep 15, 2014, at 12:12 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>> 
>> 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.
>> 
>> 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."
>> 
>> 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)?
>> 
>> - Jeff T
>> 
>> 
>> From: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
>> Date: Monday, September 15, 2014 11:50 AM
>> To: Jeff Thompson <jefft0 at remap.ucla.edu>
>> Cc: "shijunxiao at email.arizona.edu" <shijunxiao at email.arizona.edu>,
>> "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: Re: [Ndn-interest] any comments on naming convention?
>> 
>> On Sep 15, 2014, at 11:33 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>> 
>> Hi Mark,
>> 
>> Thanks for the clear summary.  You say "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?
>> 
>> 
>> 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?
>> 
>> 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.
>> 
>> Marc
>> 
>> - Jeff T
>> 
>> From: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
>> Date: Monday, September 15, 2014 11:20 AM
>> To: "shijunxiao at email.arizona.edu" <shijunxiao at email.arizona.edu>
>> Cc: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: Re: [Ndn-interest] any comments on naming convention?
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> One solution is to declare many new TLV types: VersionComponent,
>> SegmentComponent, TimestampComponent, etc.
>> 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.
>> 
>> 
>> 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.
>> 
>> Marc Mosko
>> 
>> 
>> On Sep 15, 2014, at 10:49 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>> 
>> Dear folks
>> 
>> I agree with @MarkStapp that Naming Conventions rev1 does not guarantee
>> version/segment components to be unambiguous.
>> 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.
>> 
>> One easy solution to this problem is: restrict the octets to be used in
>> regular names.
>> In rev1, we could require regular NameComponent to start with a valid UTF8
>> character.
>> In alternate proposal, we could forbid regular NameComponent to start with
>> "_".
>> However, this solution is undesirable, because some applications do need to
>> operate with binary components (eg. SignatureBits component in signed
>> Interest).
>> 
>> NDN-TLV 0.2.0 (unapproved spec) introduces NumberComponent to indicate a
>> component is a number.
>> This is insufficient because it doesn't say the meaning of a number: is it a
>> version number or a segment number?
>> 
>> One solution is to declare many new TLV types: VersionComponent,
>> SegmentComponent, TimestampComponent, etc.
>> 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.
>> 
>> 
>> If I'm to redesign the convention, I would introduce a MarkedComponent TLV
>> type.
>> The MarkedComponent TLV can appear in place of NameComponent.
>> The value part of a MarkedComponent contains a VAR-NUMBER which is a marker
>> code, followed by zero or more arbitrary octets.
>> 
>> Name ::= NAME-TYPE TLV-LENGTH (NameComponent | MarkedComponent)*
>> FinalBlockId ::= FINAL-BLOCK-ID-TYPE TLV-LENGTH (NameComponent |
>> MarkedComponent)
>> MarkedComponent ::= MARKED-COMPONENT-TYPE TLV-LENGTH VAR-NUMBER BYTE*
>> 
>> The canonical order is defined as:
>> 
>> A MarkedComponent is less than any NameComponent.
>> Two MarkedComponents are compared by their length and value, in the same way
>> as NameComponent.
>> 
>> 
>> The benefits of this solution is:
>> 
>> Version/segment/etc components are distinguished from regular NameComponent,
>> because they have a distinct TLV-TYPE: MarkedComponent.
>> 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.
>> Encoding marker code as VAR-NUMBER allows much larger marker space than
>> restricting to one-octet marker.
>> 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.
>> 
>> 
>> 
>> Yours, Junxiao
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>