NFD » NDN Specifications

generic URI accepts tons of different representations and, given a potential divergence of implementations, you cannot assume a single URI form, which is simply a human-readable form. There is a strict representation on the wire.

I strongly disagree on allowing 1= on ImplicitSha256DigestComponent (and likewise 2= on ParametersSha256DigestComponent defined in #4658), because the encoding format after the equal sign is completely different from "other typed name components". ImplicitSha256DigestComponent uses plain HEX encoding after the equal sign, while other types use percent encoding.

I weakly disagree on allowing 8= on GenericNameComponent. It is best to enforce only one encoding format and no other, so that names can be compared for equality via their URI string. Permitting multiple formats can break existing applications, and NDN Regular Expressions in particular.

We need to be careful when we change the NDN URI specification to support a different representation for a new typed name component.
For instance, if a new component with TLV-TYPE=42 is introduced and we specify that it can be URI-encoded as FooComponent=<value>, all "old" URI decoder implementations are broken because they won't be able to decode a URI containing such a component.

Junxiao Shi wrote:

I strongly disagree on allowing 1= on ImplicitSha256DigestComponent (and likewise 2= on ParametersSha256DigestComponent defined in #4658), because the encoding format after the equal sign is completely different from "other typed name components". ImplicitSha256DigestComponent uses plain HEX encoding after the equal sign, while other types use percent encoding.

As I said in note-3, we cannot break backward compatibility every time we introduce a new typed name component. The "generic" syntax (<type in decimal>=<percent-encoded value>) must always be allowed.

so that names can be compared for equality via their URI string. Permitting multiple formats can break existing applications, and NDN Regular Expressions in particular.

Using string equality on URIs is wrong and already broken. Don't do it. There isn't a single string representation of a URI.