Skip to Content

URIs and URLs: Quick Reference

It has been explained elsewhere what the difference between URIs and URLs is. The type of URL that one generally sees is an HTTP URL. You can think of the family of URIs rather like in the diagram below, showing some of the most commonly encountered URIs (not by any means a complete list).

All of the URL protocols are associated with commonly used Internet services, of which the World Wide Web is only one, using the HTTP(S) scheme. The secure variants are mostly provided using the Secure Sockets Layer (SSL) or its successor Transport Layer Security (TLS), except in the case of Secure Shell (SSH) which has its own built-in encryption protocol. Unless non-secure data is being transmitted, e.g. ordinary web pages not containing sensitive information, it is almost always a good idea to use the secure varieties of the URL protocols - unless, for example, the data is being sent via an SSH tunnel, or else other security providing protection from both external and other local users is in place: a Virtual Private Network (VPN), for example, will not prevent snooping from other users of that private network. The default ports (a colon then a number) are generally assumed where omitted, although technically there is nothing preventing the use of a non-standard port except the inevitable confusion with other services using those ports. There are well known alternative ports used by developers for testing and similar purposes, e.g. port 8080 instead of the usual 80 for web servers.

While most users will not need to know the protocol syntax for the majority of the URL schemes apart from HTTP(S), and will almost certainly never need to know about the syntax of URN schemes, nevertheless these services underlie the functionality of the Internet services that they use every day. It is at least a good idea to understand the basic pattern, which most schemes share, together with an understanding of when and how to use SSL/TLS. Most users will know roughly how an HTTP(S) URL works, which follows the basic pattern used in most of the other URL schemes. Some protocol schemes are rarely seen expressed as an address in actual software implementations, even though they are widely used: this depends on the purpose and nature of the protocol, and to some extent on whether or not it is ever directly accessed from a command line tool in practice. Most non-technical users never do this except in the case of typing Web addresses into the address bar of a browser, which is why only the HTTP(S) protocol is ubiquitous to the general public.

You will notice that the URL scheme (for locating resources) has a large number of very commonly used protocols, whereas the URN scheme (for naming resources) is not as well known but remains technically important for more complex naming schemes, where more specific semantics are required. These are typically used by libraries and in developing Internet services that require access to large data sets about electronic and real-world resources, but are not seen by the average Internet user. Officially, all of these schemes are URI schemes, including both URLs and URNs, but here they are separated by those that locate resources and those that do not.

    URI
     |
     +--- URL
     |     |
     |     +--- HTTP e.g. http://www.google.com/ (using default port 80, equivalent to http://www.google.com:80/)
     |     |     |
     |     |      +--- HTTPS (secure/encrypted) e.g. https://accounts.google.com/ServiceLogin (using default port 443, equivalent to https://www.google.com:443/)
     |     |
     |     +--- SMTP e.g. smtp://bob.fisher@mymailservice.com:25 (also mailto: bob.fisher@mymailservice.com)
     |     |     |
     |     |     +--- SMTPS (secure/encrypted) e.g. smtps://bob.fisher@mymailservice.com:585 (also mailto: bob.fisher@mymailservice.com)
     |     |  
     |     +--- POP3 e.g. pop://bob.fisher@mymailservice.com:110 (for downloading email from a remote server)
     |     |     |
     |     |     +--- POP3S (secure/encrypted) e.g. pops://bob.fisher@mymailservice.com:995
     |     |
     |     +--- IMAP4 e.g. imap://bob.fisher@mymailservice.com:143 (for synchronising email with a remote server)
     |     |     |
     |     |     +--- IMAP4S (secure/encrypted) e.g. imaps://bob.fisher@mymailservice.com:993
     |     |
     |     +--- FTP e.g. ftp://bob.fisher@myserver.com:/my_folder_path/my_file.example (or ftp:bob.fisher@myserver.com:21/my_folder_path/my_file.example)
     |     |     |
     |     |     +--- FTPS e.g. ftps:bob.fisher@myserver.com:990/my_folder_path/my_file.example (it is now more normal to use SFTP via SSH instead)
     |     |
     |     +--- XMPP e.g. xmpp://bob.fisher@mychatservice.com:5222 (e.g. for GTalk, Facebook, jabber.org or other open protocol instant messaging)
     |     |     |
     |     |     +--- XMPPS (secure/encrypted) e.g. xmpps://bob.fisher@mychatservicecom:5222 (over the same default port or the legacy 5223)
     |     |
     |     +--- IRC e.g. irc://myircserver.org:6667/#mychatchannel
     |     |     |
     |     |     +--- IRCS (secure/encrypted) e.g. irc://myircserver.org:6697/#mychatchannel
     |     |
     |     +--- TELNET e.g. telnet://bob:mypassword@myserver:23 (highly insecure for command line access but occasionally used for other purposes)
     |           |
     |           +--- TELNET (secure/encrypted), as above but using SSL and either the same port or the SSH port 22, usually abandoned in favour of SSH
     |           |
     |           +--- SSH (secure/encrypted) e.g. ssh://bob:mypassword@myserver:22 (for command line access and related purposes)
     |           |
     |           +--- SFTP (secure/encrypted) e.g. sftp://bob:mypassword@myserver:22 (for file downloads, with the related UNIX/LINUX/POSIX scp command)
     |
     +--- URN (these examples were taken from Wikipedia)
     |           |
     |           +--- International Standard Book Number (ISBN) e.g. urn:isbn:0451450523 (the book The Last Unicorn, by Peter S. Beagle, 1968)
     |           |
     |           +--- International Standard Audiovisual Number (ISAN) e.g. urn:isan:0000-0000-9E59-0000-O-0000-0000-2 (the film Spider-Man, 2002)
     |           |
     |           +--- International Standard Serial Number (ISSN) e.g. urn:issn:0167-6423	 (the scientific journal Science of Computer Programming)
     |           |
     |           +--- Request For Comments (RFC) for memoranda of the Internet Engineering Task Force (IETF) on internet standards and protocols, e.g. urn:ietf:rfc:2648
     |           |
     |           +--- MPEG7 e.g. urn:mpeg:mpeg7:schema:2001 (the default namespace rules for MPEG-7 video metadata)
     |           |
     |           +---  Object Identifier (OID), e.g. urn:oid:2.16.840 (the United States of America)
     |           |
     |           +--- UUID e.g. urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 (a type of unique identifier that is mathematically improbable to duplicate, version 1)
     |           |
     |           +--- National Bibliography Number (NBN) e.g. urn:nbn:de:bvb:19-146642 (a document in the Bibliotheksverbund Bayern, Germany, with library and document number)
     |           |
     |           +--- European Union Directive e.g urn:lex:eu:council:directive:2010-03-09;2010-19-UE (using the Lex URN namespace for legislation)
     |     
     +--- URC (internet standard proposal never developed, largely replaced by XML, RDF, JSON etc in providing metadata)

As noted, Uniform Resource Characteristics (URC) were abandoned in the early history of the internet. Numerous anomalies have developed, such as that noted above where both FTPS and SFTP perform similar functions in a different way, or where some services use a different port for SSL/TLS but XMPP usually does not. The Digital Object Identifier (DOI) scheme is effectively a URN scheme but has never been registered as such and performs the same function whilst officially remaining a URL scheme.



Dr. Radut | blog_post_tf