N2T.net logo

RESOLVING
Names to Things

About
N2T Partners
API Documentation

What is Suffix Passthrough?

Suffix Passthrough (SPT) is a feature that a resolver (a web server that specializes in forwarding incoming requests) might support in order to greatly increase the number of identifiers that it can forward. N2T.net supports this feature for all identifiers that it stores.

SPT dramatically reduces the burden of maintaining multiple identifiers by permitting one identifier to stand in for many. In fact there is no limit to how many, and N2T has hundreds of stored ARKs, each one standing in for thousands. The way it works, given a URL for a stored identifier, if it arrives with an appended suffix, N2T will re-append it ("pass it through") to the identifier's stored forwarding destination during resolution. Usually end providers leverage SPT by publishing (advertizing) URLs with specific suffixes that they know will return provider content. While less common, nothing prevents an end user from using a provider's suffix pattern to append suffixes that also resolve correctly.

Basically, Suffix Passthrough makes every ARK the root of its own "namespace". Any provider-added (or user-added) suffix, which is a common way to form sub-object identifiers, will be passed through to the stored target object. For example, a dataset with 10,000 component parts and just this one "ancestor" ARK,

http://n2t.net/ark:/12345/x98765

would effectively allow access to 10,000 ARKs, but only require you to manage the ancestor ARK. Those sub-object ARKs might look like:

http://n2t.net/ark:/12345/x98765/study1/location1/day1.cs
http://n2t.net/ark:/12345/x98765/study1/location3/day19.cs
 ...
http://n2t.net/ark:/12345/x98765/study92/location18/day96.xlsx
A suffix passing from the end of a submitted ARK to the end of a stored target URL.

When a user clicks on one of those ARKs, it is submitted to N2T. Failing to find it stored, N2T scans backwards starting from the end of the user-supplied ARK string and stops at the first ancestor ARK that is stored.

The part that was scanned over, stretching from the first stored ancestor ARK to the end of the original string, comprises the suffix.

http://n2t.net/ark:/12345/x98765/study92/location18/day96.xlsx
\______________________________/\____________________________/
          ancestor ARK                      suffix

Then it redirects the user's browser to the ancestor's target URL, appending the suffix that it scanned. So if the ancestor ARK's target was,

http://n2t.net/ark:/12345/x98765  -->  http://datazoo.example.com/carbon288
\______________________________/       \__________________________________/
       ancestor ARK                          ancestor ARK's target URL

the user would be (hypothetically) redirected to

http://datazoo.example.com/carbon288/study92/location18/day96.xlsx
\__________________________________/\____________________________/
       ancestor's target URL                    suffix

Note that SPT is only useful when the target server can respond to the suffixes it receives. For example, you would not instruct users how to add suffixes to the above ARK unless the target server was prepared to provide access to its 10,000 sub-objects. Fortunately, SPT is easy to illustrate in some cases, such as when the target server extends resource names with query strings or ordinary URL paths.

Rule: if identifier A has target T, suffix passthrough means the extended identifier A/X has targetT/X.

Using more words, for an identifier A stored in N2T that has the target URL T, if you add a suffix X to A and resolve (eg, click on) the URL A/X, you will be redirected to the URL T/X.

Some limitations and exceptions apply. For example, during the backwards scan, potential ancestor ARKs are tested (to see if they are stored) only at each "word" boundary, where a word here means a string of letters and digits. Also, scanning stops when the NAAN (the 5-digit number after the "ark:/") is reached.

Suffix Passthrough Examples

You can see SPT in action by clicking on the extended ARKs below. These are "ARKs" (for illustration purposes only, not long-term stable) that are not stored in the N2T resolver, but are formed by adding a suffix to an ARK that is stored.

Example 1. One stored ARK standing in for several CDL service page "ARKs".

Example 2. One stored ARK standing in for any number of Wikipedia article "ARKs".

Example 3. One stored ARK standing in for any number of internet search "ARKs".

You can experiment easily by pasting this stored ARK,

http://n2t.net/ark:/12345/fk3

into your browser's location field and appending (no spaces) a "search term" suffix of your choice.

Last modified: 2021-03-07