[Ndn-interest] any comments on naming convention?

Tue Sep 16 10:53:16 PDT 2014

I am not sure why something being a typed name is related to routing.  Isn’t routing going to be over the full TLV representation of the name?  Or do you consider the TLV “T” as separate from the name component and not used in FIB or PIT matching?

I think a serial version is more useful than a timestamp version.  In CCNx 1.0, we have a type for both, but we generally use the serial version.  A timestamp does not give distributed versioning, so like a serial version it is only useful from a single publisher and it gives an easy way to determine the next version.  It does, of course, require that the publisher maintain state rather than rely on its real-time clock (or ntp) for its version number.  A serial version number also allows unlimited version number generation, whereas a quantized (e.g. milli-second) timestamp limits the number of versions one can generate at a time without keeping state. 

As a general philosophy on named addresses, I see the hierarchical name components as providing protocol encapsulation, essentially encapsulating name components to the left (not all components are like this, but some are).  For example, when you add a version component to a name it is a statement that a versioning protocol has encapsulated and possibly modified the content object identified by the left name.  When a segmentation protocol is applied to a content object, it encapsulates a name to the left.  They serve a similar purpose to header encapsulation in traditional packets.  Therefore, I think that when a protocol is encapsulating the left-name, those should be unambiguous and explicit.  

For protocols that everyone needs to understand, like versioning or segmenting, those should be a standardized value, and not exclusive of other protocols.  Someone might come out, for example, with a better segmentation protocol and that should have a different identifier than the earlier segmentation protocol.  Therefore, wherever you do your multiplexing you need to coordinate.  That’s going to be either in the TLV “T” or in the “key” of a “key=value” inside the “V”.

Marc

On Sep 16, 2014, at 10:21 AM, Tai-Lin Chu <tailinchu at gmail.com> wrote:

> Summarize all types that people need (feel free to add some, and paste
> in your reply)
> - regular
> - segment
> - version (timestamp)
> - signature
> - key: assuming that the next regular component will be value. The
> value is empty if it sees another key component immediately after.
> - app-specific
> 
> 
> However, I am not convinced that we need version, signature, and
> app-specific as typed component. Will these change how packet routes?
> 
> 
> 
> On Tue, Sep 16, 2014 at 8:47 AM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Hi Jeff
>> 
>> Please see my proposal of MarkedComponent
>> <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html>,
>> which is a solution to eliminate ambiguity by defining a new type
>> specifically for key-value pair.
>> 
>> Yours, Junxiao
>> 
>> On Tue, Sep 16, 2014 at 8:18 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>> 
>>> 
>>> Second, if the most important issue is eliminating ambiguity/aliasing,
>>> then why not define a new type that hints that the component can be
>>> interpreted as a key/value pair with some encoding convention?  This could
>>> enable an unambiguous, short list of commonly used conventions that you've
>>> mentioned (using marker-like keys),  while keeping information describing
>>> the data object in the name. It would also be very useful for applications
>>> that desire their own k/v representation for components, which Dave has
>>> argued for in other circumstances and we keep running across. It doesn't
>>> rule out use of hierarchy, and doesn't limit what an application defined
>>> keys could be.  Yet, it could be ignored in forwarding (just another
>>> component) and perhaps have a still-meaningful sort order (key, then
>>> value).
>>> 
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140916/af100ef7/attachment.bin>