Re: [icnrg] Questions about an empty name segment

[<[e-mail]>]

Dr. Ooka,

Thank you for the question, as there are several important distinctions here.

=================
Definitions
=================

A Name has two primary use cases: (1) in a protocol message and in the PIT, (2) in an implementation’s FIB.

In case 1, the syntax of a Name is defined in the ABNF of [2], which correspond to the “exact” name concept (Sec 3 of [2]).  It identifies a specific content object, but not including the ConObjHash restriction (which would make it a “full” name).

In case 2, in the FIB, one wants the ability to specify the “prefix” name concept.  These specify a prefix of an exact name.

In a protocol message (case 1), the Name maybe (1.a) missing, (1.b) exactly 1 name segment, where the 1st name segment cannot be 0 length, or (1c) more than 1 name segment, where the 1st name segment cannot be 0 length, but any or all subsequent name segments could be 0 length.  In case 1.a, it is a so-called nameless object and processed as per the specs; note that here the name is missing, it is not a 0-length name.  In the PIT, the name is the same as it is in a protocol message (as the PIT records the protocol message’s name).

In the FIB in case 2, you can have (1.b) or (1.c) or a (2.a) 0-length name, or (2b) a 1-segment name with 0-length.  In case 2.a, this is considered the default route and would match any name.  In case 2.b, it is a typed default route and would match any name with a specific first name segment type.  In cases 1.b or 1.c, it works the obvious way.

In ccnxmessages, a 0-length name is defined as the NAME TLV with T = T_NAME, L = 0.  A 1-segment name with 0-length is (T = T_NAME, L = 4, V = (T = x, L = 0)), where x is some name segment type.

Note that in the specs we do not say how an implementation must encode a default route in its FIB.  We only specify how it is externally represented in the CCNX URI spec.  The actual value in the FIB or how the the implementation uses a default route is up to the implementation.  The default route, for example, could be in a separate data structure and only used if there’s no match in the FIB.

=================
Usage
=================

In an application (and thus in protocol messages), I do not think it is typical for a name segment to be empty, but this is a way to express a null value.  In CCNx 0.x, for example, a 0-length name segment was sometimes used because it was always short-lex sorted before any other value in the name segment.  Sometimes it used a 0-length name segment to represent the value “0” rather than encode a %00.  In CCNx 1.0 (the IETF spec), we steered away from this sort of usage because saving 1 byte was not considered as important as avoiding the confusion this sort of usage engendered.  Also, a competent compression scheme would fix the byte usage.  We preferred to encode a 0 as %00 and encode null as 0-length.

Here is a simple made-up example.  An application might have some application-defined name components where the name components might be “first_name” and “middle_name” and “family_name”.  Some people might not have a middle_name and in that case the application could represent null as a 0-length name component.  Another way to represent this would be to discard the middle_name name component.

Examples: 
ccnx:/name=foo/name=bar/name=my_app/APP:00=alice/APP:01=jane/APP:02=smith
ccnx:/name=foo/name=bar/name=my_app/APP:00=bob/APP:01=/APP:02=tucker

In a certain application, perhaps we use distinguished first name component types to distinguish a service, where we want different routing based on the _type_ of the name component, not the actual name.  For example, these two names should have different routing:

ccnx:/APP:00=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
ccnx:/APP:01=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=

Note that we are routing on the name component _type_ not the _value_.

This same technique can also be used mid-way through the name, such as to distinguish between /NAME=foo/APP:00=silver and /NAME=foo/APP:01=silver.  

Marc


> On Oct 22, 2018, at 3:23 AM, Atsushi Ooka <[e-mail]> wrote:
> 
> Dear all.
> 
> I have some questions about an empty name segment
> such as "ccnx:/NAME=" and "ccnx:/foo/bar/NAME=".
> 
> Why is an empty name segment needed, and how can it be used?
> 
> I have read Internet-Drafts (IDs) [1,2,3] and
> confirmed the behavior of Metis [4] and iping [5];
> however, it is not clear for me how to use them.
> 
> Thank you in advance.
> 
> Best regards,
> Atsushi Ooka
> 
> [1] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08
> [2] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxsemantics-09
> [3] https://tools.ietf.org/html/draft-mosko-icnrg-ccnxurischeme-01
> [4] Metis (FD.IO sb-forwareder) https://wiki.fd.io/view/Sb-forwarder
> [5] iping (FD.IO libicnet) https://wiki.fd.io/view/Libicnet
> 
> ----------------------------------------------------------------------
> Atsushi Ooka, Ph.D.
> 
> Network Science and Convergence Device Technology Laboratory,
> Network System Research Institute,
> National Institute of Information and Communications Technology (NICT)
> 
> E-mail: [e-mail]
> Tel: [phone]
> URL: http://www.nict.go.jp
> ----------------------------------------------------------------------
> 
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg