[Ndn-interest] any comments on naming convention?

Burke, Jeff jburke at remap.UCLA.EDU
Tue Sep 16 08:18:10 PDT 2014


Since I made it, let me explain that the intention of the "type explosion"
comment was not the fear-mongering that you are suggesting. :) Rather, it
was an attempt to explore the potential consequences of a design choice by
posing the logical extreme... The examples didn't get captured in that
doc, sorry. I don't know that it's so unimaginable that applications would
start using T-V pairs loosely if allowed. Maybe we can chat at ICN about
this. (This paper has been an interesting one to think about with respect
to k/v descriptions of NDN data objects -

I agree that applications using types for their own purposes is likely not
a sufficient reason to discard the approach.  But two questions I could
still use some help on:

First, in the document I sent, there are seven specific, though not
equally well considered, reasons to use marker components that have
nothing to with the so-called type explosion.  As far as I can tell, no
one has addressed these from the application developer's perspective.
Could someone?   

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


On 9/16/14, 4:58 PM, "Mark Stapp" <mjs at cisco.com> wrote:

>There's a difference between saying "someone else" made some assertion,
>and that assertion's being supported with facts - isn't there? No one
>has demonstrated how the number of name-component types that need to be
>unambiguously indicated in packets is reduced by the use of
>"conventions." And no one has demonstrate that an extremely large number
>of standard name components is needed. The discussion has been about a
>handful of types:
>- segment
>- version
>- maybe timestamp (but that could be in 'version' too if necessary)
>- maybe signature (for things like Jeff's signed interests. but again
>that could be in an opaque or app-specific component if there's no
>expectation that the network or the general-purpose stack/client lib
>will need to process the thing)
>I can imagine a couple more (like 'message digest' for self-certifying
>names), and I think the PARC folks have thought of a couple. but that's
>still pretty much a "handful", not an "explosion." And I'm sure there
>will be plenty of discussion about everything beyond the core four or
>I haven't seen anyone say anything like "I don't think we need
>segmentation, I hate segmentation." I haven't seen anyone say "I have a
>way to make a _convention_ safer or more robust than an explicit
>name-component type." And I haven't seen anyone say "here's a list of
>ten thousand standard components that we would have to introduce if we
>left the UTF8 convention behind." So let's not keep throwing the
>"explosion" word around until it's supported with some actual substance.
>I have to point out that when the issue of the ccnb encoding was raised
>a couple of years ago, there were a lot of the same arguments made: that
>TLVs weren't sufficiently flexible, that applications didn't want TLVs,
>that we couldn't predict what we might need in the future. The reality
>is that applications that didn't care then still don't care - they
>wanted APIs to use, and didn't really care about the bits-on-the-wire
>representation. TLVs didn't harm them. But there are other parts of the
>network, and those parts (the client software stack, the forwarders, the
>caches) really benefitted from the encoding change.
>A similar thing is going on here, imo. There's no evidence that there
>will be a name-component "type explosion", but the phrase is out there
>and it sure sounds scary. In fact, we're talking about a handful of
>well-known component types, just a handful, that need to be visible
>outside the application namespace, and we all actually seem to agree
>about the initial set. The encoding change is opaque to applications
>that don't care about the actual details of the encoding, but it's very
>beneficial to other parts of the software stack and the overall network.
>There are only benefits to removing encoding ambiguity and aliasing by
>removing the use of "conventions." And there will be plenty of
>back-pressure if folks come forward and want to allocate additional
>values from the well-known space.
>Ndn-interest mailing list
>Ndn-interest at lists.cs.ucla.edu

More information about the Ndn-interest mailing list