[Ndn-interest] any comments on naming convention?

[Dave Oran (oran)]

On Sep 15, 2014, at 1:49 PM, 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.
> 
I believe that given the tradeoffs, this is the best approach. Why?

- old consumer applications won’t understand a new naming convention no matter how we do it. The question is what is “safe” for them to do. For this we need a “meta-convention” about how to treat typed name components not understood by an application. Here, there’s a quite straightforward solution, which is that if the typed name component include a “genericNameComponent” type, you simply say if you don’t understand the name component type you treat it as if it were “genericNameComponent”

- routers probably should not be required to interpret names in the first place, so this is a non-issue. However, if we define the above meta-convention for applications, we simply say routers treat all name component types as if they were genericNameComponent.

- if somebody can come up with a persuasive reason for a router to understand some of the name component types, we can specify that in the architecture and deal with forward compatibility issues that might arise on a case-by-case basis. (I can actually think of a few clever uses, but don’t want to incite a flame-war by suggesting these).


> 
> 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.
I don’t see a significant different between using the TLV or a marker in terms of flexibility. In either case you need a registry to avoid collisions. Using the “T” of a TLV for a name component has the substantial advantage of fitting directly in with the basic parsing machinery.

> 	• 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