[Ndn-interest] any comments on naming convention?
Mark Stapp
mjs at cisco.com
Tue Sep 16 06:58:01 PDT 2014
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 five.
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.
Thanks,
Mark
More information about the Ndn-interest
mailing list