[Ndn-interest] any comments on naming convention?

Tai-Lin Chu tailinchu at gmail.com
Mon Sep 15 11:14:08 PDT 2014


I love your solution :)
I don't think ndn-tlv 0.2 should add numberComponent; instead
markerComponent should be introduced.


On Mon, 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
>



More information about the Ndn-interest mailing list