[Ndn-interest] any comments on naming convention?

[Junxiao Shi]

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
<http://gerrit.named-data.net/gitweb?p=NDN-TLV.git;a=blob;f=name.rst;h=922bb1cdd568e90bb9e36e8b9339d6c819d2cf06;hb=1ac334640da059791ad5c75637eee075fd0b87b3#l11>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140915/e48604c4/attachment.html>