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 Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  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)

Previous Topic/Section
URL Obscuration, Obfuscation and General Trickery
Previous Page
Pages in Current Topic/Section
12
3
Next Page
TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
Next Topic/Section

Uniform Resource Names (URNs)
(Page 3 of 3)

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.

Key Concept: Since URNs identify resources by name rather than location, they are a more natural way of identifying resources than using URLs. Unfortunately, this advantage is also a disadvantage, since URNs don’t, by themselves, provide a user with the necessary information to find the resource so it can be used. A process of URN resolution must be performed to transform the URN into a set of information that allows the resource to be accessed.


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.

 


Previous Topic/Section
URL Obscuration, Obfuscation and General Trickery
Previous Page
Pages in Current Topic/Section
12
3
Next Page
TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.