[Ndn-interest] any comments on naming convention?

[Mark Stapp]

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