NFD » NDN Specifications

Hi Felix. First of all, thank you for all the helpful pull requests! I merged them all.

You raise a good question for the use of the "relative" value of ".." in the NDN URI scheme, which is documented here:
http://named-data.net/doc/ndn-tlv/name.html#ndn-uri-scheme

The documentation is unclear on how to treat "..", so I asked on the development email list. I'll update this Redmine issue with the response.

RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" says:
The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative-path reference to indicate relative position within the hierarchical tree of names. Therefore, if ".." appears within an absolute ndn URI, the entire URI is invalid and should raise an error.

So, since the .. in "/a/b/../c" is illegal, it is simply ignored instead of raising an error for the entire name. Therefore, the result is "/a/b/c". The other "illegal" possibilities for dot are "no dot" and "one dot", for example "/a/b//c" and "a/b/./c". It these cases too, it is ignored and the result is "/a/b/c".

Does that seem reasonable?

Thanks for the reference, but I don't think the "therefore" part in your argumentation is correct. Just because the idea behind providing the .. path segments is so that relative-path references can "move up" a base path, it does not make other uses invalid. As I understand it, a .. segment within an absolute path is valid.

See https://tools.ietf.org/html/rfc3986#section-5.2 and the examples at its end. Also, for example, the link http://redmine.named-data.net/issues/12345678/../1818 leads to this very issue, conforming to https://tools.ietf.org/html/rfc3986#section-6.2.2.

Btw (and this should belong to a new issue if valid), shouldn't http://named-data.net/doc/ndn-tlv/name.html#ndn-uri-scheme read "any component that consists solely of ZERO or more periods is encoded using three additional periods"? I don't remember where, but I thought other documentation specified that an empty path segment would become .... (Three dots.)

By "empty path segment" I meant "empty NDN path component".

Felix Rabe wrote:

shouldn't http://named-data.net/doc/ndn-tlv/name.html#ndn-uri-scheme read "any component that consists solely of ZERO or more periods is encoded using three additional periods"? I don't remember where, but I thought other documentation specified that an empty path segment would become .... (Three dots.)

The three dots is deprecated since the presence of an empty component in a Name is deprecated, but it is still supported in ndn-js.

The three dots is deprecated since the presence of an empty component in a Name is deprecated, but it is still supported in ndn-js.

In fact, "three dots" shouldn't deprecated, because #1932 permitted empty NameComponent again.

NDN-TLV cites RFC3986 for URI, which defines how to resolve ".." component in URI.

No further edits are needed in NDN-TLV for this matter.

It's just a problem of how libraries conform RFC3986 regarding URI resolution.