Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP Application Layer Addressing: Uniform Resource Identifiers, Locators and Names (URIs, URLs and URNs)

URL Obscuration, Obfuscation and General Trickery 1 2 3 TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)

URN Resolution and Implementation Difficulties

URNs are a more “natural” way of identifying resources, which gives them intuitive appeal. Despite this, URNs are still not widely used, even though they have been in development for over a decade. The main reason for this is somewhat ironic: it is in fact because of the fact that URNs are independent of location. The very characteristic that provides URNs with identification advantages over URLs also makes URNs much harder to use practically, which has led to long delays in workable URN systems.

To understand the problem, consider the example string “URN:isbn:0-679-73669-7”. This uniquely identifies a particular book, and will always refer to it no matter where the book may be, unlike a URL. The problem is that while the URL-equivalent tells us how to actually find this book, the URN does not. The same thing goes for our human example before: identifying Joe Xavier Zachariah by his name is more “sensible” than identifying him as “the man living at 44 Glendale Crescent in Sydney, Australia”, but at least with the latter, we know where Joe is!

In order for URNs to be useful on an internetwork, they require an additional mechanism for translating a simple URN identification string into a particular location and/or access method. In other words, we need to be able to change a URN into the equivalent of a URL, so that the resource can be found. This requirement is analogous to the problem of resolving Internet DNS domain names into IP addresses, and the same term is used to describe it: URN resolution.

Ideally, we want to be able to use some sort of technique where we specify the name “Joe Xavier Zachariah” and we are told where Joe is so we can find him. Or, we provide the string “URN:isbn:0-679-73669-7” and are provided with a list of libraries or other places where the book can be found. The power of URNs can also be exploited in such a system, by having the resolution system specify the location of a copy of the resource that is closest (in terms of network distance, cost or other measurements) to the entity making the request.

However, setting up URN resolution mechanisms is a non-trivial task. The matter of URN resolution has been the subject of much of the work on URNs over the last decade. RFC 2483, URI Resolution Services Necessary for URN Resolution, was published in 1999 and discusses some of the important issues in URN resolution. In October 2002, a series of RFCs, 3401 to 3405, defined a new system called the Dynamic Delegation Discovery System (DDDS) that was designed not just to resolve URNs, but to handle the entire class of resolution problems where an identifier is given and the output is information about where to get more information about that identifier. RFC 3406 was published at the same time, providing more information about URN namespaces.

Although progress on URNs has been slow, it has been steady. While it may yet be a few years before URNs are widely used, I believe it is likely that they will play an increasingly prominent role in identifying resources on the Internet in the future.

URL Obscuration, Obfuscation and General Trickery 1 2 3 TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)