[Ndn-interest] v0.3 spec and separating matching

[christian.tschudin at unibas.ch]

second attempt, reformulating things around "forwarding hints"

To me, an interesting thing in v0.3 is the introduction of a control 
parameter, telling how to apply an Interest's name when it comes to 
matching with content:

- if CanBePrefix is set, do it "prefixly"
- if CanBePrefix is not set, do it "exactly"
- if digest is present, do it "fully"

Together with the MustBeFresh and the digest parameter, this is the 
start (or remainder) of a content filtering language.

My point was that classifying names according to that matching mechanics 
is misleading and even imprecise language, because 'exact', 'full' etc 
are not intrinsic properties of a data object's name - it's rather a 
question of how you interpret "the bits that are in a field called 
Name".

And taking it a step further, I wondered whether the Interest's Name 
element shouldn't be reassigned to its primary role of an interest 
packet, namely directing the Interest towards potential data sources, 
having forwarding hints only, and make this field independent of the 
data object's name bits.

The filter expression needs its place, too, of course. Exposing filter 
parameters ('canBePrefix,mustBeFresh) at the Interest's top level seems 
natural and efficient for CS purpose, but --just a playful thought-- one 
could also put a BPF in the Parameters element. (And of course move from 
'filter' to 'generator').

In an attempt to summarize: In spec v0.4, what about renaming the "Name" 
element into "Directions"?

best, c