Um URI (Uniform Resource Identifier - Identificador Uniforme de Recurso) pode ser classificado como um Localizador (URL, Uniform Resource Locator - Localizador Uniforme de Recurso) ou um Nome (URN, Uniform Resource Name - Nome Uniforme de Recurso), ou ainda como ambos (rfc3305).

RFC significa Request for Comments (Pedido/Requisição para Comentários), são documentos técnicos desenvolvidos e mantidos pela IETF (Internet Enginnering Task Force), instituição que especifica os padrões que serão implementados e utilizados em toda a internet no mundo.

No final tem um resumo para quem estiver sem tempo (ou sem vontade) de ler esse texto todo.

Para fins de entendimento, "Solicitação" é o URI, é a sequência completa de caracteres e "Requisição" é a Request-URI. A Request-URI está dentro do URI.

Um Uniform Resource Identifier (URI - Identificador Uniforme de Recurso) é uma sequência de caracteres que identificam um recurso abstrato ou físico (rfc3986). É uma sugestão de como deve ser a sequência de caracteres e partes que compõem o URI sendo que esta especificação não define uma gramática para URIs, essa tarefa deve ser executada pelas especificações individuais de cada URI.

URI é um termo genérico, é uma forma generalizada de denominar tanto URLs quanto URNs.

As RFCs aconselham chamar tudo de URI para evitar confusão.

A sigla URI não se aplica somente ao que é digitado na barra de endereços de um navegador, por exemplo, o comando no terminal "cd /etc/systemd/system" é considerado um URI, sendo que a parte "/etc/systemd/system" é a Request-URI, é o recurso a ser buscado, como veremos adiante.

URI, em se tratando especificamente de navegadores, é aquilo que se digita na barra de endereços do navegador seguindo-se uma sequência correta.

Um Recurso (Resource), conforme a rfc1736, seção: "2.1.4. ...um recurso.

Um recurso pode ser muitas coisas. Além de "non-networked" ou "non-electronic", recursos que acabamos de mencionar, exemplos conhecidos são documentos eletrônicos, uma imagem, um servidor (por exemplo, FTP, Gopher, Telnet, HTTP) ou uma coleção de itens (por exemplo, menu Gopher, diretório FTP, Página de HTML).

Outros exemplos acompanham protocolos multifuncionais como como Z39.50, que podem executar acesso único à rede de ida e volta, refinamento de pesquisa orientado a sessão e navegação de índice."

Obs.: Recurso "non-networked" ('sem rede' ou 'fora da rede') é um conceito genérico e significa que pode ser um recurso buscado dentro do próprio computador e "networked" é um recurso da rede na qual se está, sendo ela interna ou externa. Recurso "non-electronic" é um conceito genérico que significa um objeto físico sem instanciação eletrônica, por exemplo, buscar/acessar/instalar um driver da placa de vídeo é um recurso "non-electronic".

O comando no terminal "cd /etc/systemd/system" é considerado um URI com um recurso (/etc/systemd/system) "non-networked" e "non-electronic", pois estamos requisitando no próprio computador e não estamos instanciando nada. Não explicarei aqui o conceito de "instanciação", pois não é o escopo, mas acredito que deu para entender. Outro exemplo bem claro de URI "non-networked": http://localhost.

A coisa parecerá confusa, pois envolve conceitos, nomes e coisas reais, porém, a culpa não é minha, é das RFCs que são um tanto confusas e desencontradas - como veremos -, mas é só abstrair (decompor em partes) e partir de onde se está para então fazer relações/comparações, por exemplo, o conceito de "non-networked": o computador buscando um recurso dentro dele mesmo em relação a uma rede interna é "non-networked" e você navegando dentro da rede interna em relação a uma rede externa é "non-networked" e uma rede externa em relação à "world wide web" é "non-networked" e a "world wide web"... sei lá em relação ao quê ela seria "non-networked", talvez em relação ao universo, mas aí já saímos do escopo de tecnologia e informática e, seguindo por esse caminho, daqui a pouco chegaremos em universos paralelos, como nas RFCs, onde eles viajam até por outras dimensões.

Por exemplo, para o URI "networked" https://www.vivaolinux.com.br/busca/?cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster temos:

• Scheme: https
• Authority: www.vivaolinux.com.br
• User Information: ausente
• Host: www.vivaolinux.com.br
• Port: ausente
• Path: /busca/
• Query: cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster
• Fragment: ausente

Scheme, Authority, etc, são partes das especificações constantes na rfc3986. O Recurso, no caso, é a busca, é a pesquisa refinada para o usuário no site Vivaolinux. A Query é a query string (a parte após o sinal de interrogação).

Uma Request-URI identifica o recurso ao qual aplicar a Solicitação.

Exemplo: https://example.org/path/to/file?param=42#fragment

A linha inteira acima é o URI.

A parte /path/to/file?param=42 é a Request-URI, a query string é a parte após o sinal de interrogação (é também aquela requisição GET que erroneamente dizem que só pode ter 255 caracteres, mas como veremos na página "POST e GET" isso depende do navegador, do servidor web, etc, pois o protocolo HTTP não limita o tamanho). A Request-URI é também a requisição solicitada pela Request-Line, que por sua vez, Request-Line é a linha completa (URI).

Mais adiante veremos que essa Request-URI é também um URL abreviado, mas vamos por partes, como o esquartejador.

Na seção "1.1.2. Examples" da rfc3986 encontramos mais exemplos de URIs. Os exemplos de URIs a seguir ilustram vários esquemas de URI e variações em seus componentes de sintaxe comuns:

• ftp://ftp.is.co.za/rfc/rfc1808.txt
• http://www.ietf.org/rfc/rfc3986.txt
• ldap://[2001:db8::7]/c=GB?objectClass?one
• mailto:John.Doe@example.com
• news:comp.infosystems.www.servers.unix
• tel:+1-816-555-1212
• telnet://192.0.2.16:80/
• urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Acrescentei esse:

• http://www.w3.org/People/Berners-Lee/

Na seção "1.1.3. URI, URL, and URN" da rfc3986 tentaremos encontrar as diferenças e semelhanças entre URI, URL e URN:

"A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name."

"Um URI pode ainda ser classificado como Localizador, como Nome ou ambos. O termo "Localizador Uniforme de Recurso" (URL) refere-se ao subconjunto de URIs que, além de identificar um recurso, fornecem um meio de localizar o recurso descrevendo seu mecanismo de acesso primário (por exemplo, sua "localização" de rede).

O termo "Nome Uniforme de Recurso" (URN) tem sido usado historicamente para se referir a ambos os URIs sob o esquema "URN" [RFC2141] que são obrigados a permanecer globalmente únicos e persistentes mesmo quando o recurso deixa de existir ou fica indisponível; e para qualquer outro URI com as propriedades de um nome."

"Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]. Berners-Lee, et al."

"Especificações futuras e documentações relacionadas devem usar o termo geral "URI" em vez dos termos mais restritivos "URL" e "URN" [RFC3305]. Berners-Lee, et al."

Aí vamos para a rfc3305:

"Este memorando fornece informações para a comunidade da Internet. Ele não especifica nenhum tipo de padrão de Internet. A distribuição deste memorando é ilimitada."

Na seção "2. URI Partitioning" encontramos:

"2. Particionamento de URI

Há alguma confusão na comunidade web sobre o particionamento do URI, especificamente na relação entre os conceitos de URL, URN e URI. A confusão se deve à incompatibilidade entre duas visões diferentes do particionamento de URI, que chamamos de visões 'clássica' e 'contemporânea'".

Daí tem o que eles consideram "Visão Clássica" e "Visão Contemporânea".

Mais adiante na seção "2.3 Confusion" (Confusão, o nome é esse mesmo), na mesma rfc3305 ainda, eles citam mais quatro RFCs que você tem de ler para "entender" somente o conceito da coisa toda.

Eu li a coisa toda até onde consegui, mas sempre chega num ponto que uma RFC cita outra(s) e vice-versa, você fica indo e voltando pulando de uma RFC para outra. Parece até o calhamaço ininteligível de leis Brasileiras, porém, o ordenamento jurídico brasileiro ganha de longe no quesito confusão.

Em suma, tanto na tal Visão Clássica quanto na tal Visão Contemporânea, todo URL é um URI, e o contrário não é verdade, pois um URI também pode ser um URN.

A única coisa que dá para ter certeza é que URI é um termo genérico, é uma forma generalizada de denominar tanto URLs quanto URNs e a própria IETF aconselha a chamar tudo de URI.

E ainda tem um tal de URC (Uniform Resource Characteristics) que não vingou.

Vamos adiante.

Uma linha inteira na barra de endereços pode ser chamada de URI como pode ser chamada de URL se tiver o localizador da página. O Localizador da página, grosso modo, é isso: /caminho/caminho/página.html ou /caminho/página.php, etc, mas não é o URL inteiro, absoluto, pois falta "protocolo://".

Essa linha "https://www.vivaolinux.com.br/perguntas/" é um URI que é um URL completo, absoluto.

Exemplo de um URN (que pode ser chamado de URI também): mailto:John.Doe@example.com

Na rfc2141 tem mais detalhado o que seria um URN:

2. Syntax

All URNs have the following syntax (phrases enclosed in quotes are REQUIRED):

<URN> ::= "urn:" <NID> ":" <NSS>

Em alguns sites que pesquisei trazem que um URN pode ser uma parte do URL, por exemplo: https://exemplo.com.br/boleto.html/#pague

O URI é a linha toda (sequência identificadora de caracteres), o URL seria a parte "htps://exemplo.com.br/boleto.html/" (o identificador do local do recurso, no caso, a página boleto.html) e o URN seria "exemplo.com.br/boleto.html/#pague" (o identificador do nome do recurso, no caso, "pague").

Pelo que se entende, URLs e URNs, quando separadas, são bem distintas entre si.

URNs são esses exemplos:

• mailto:John.Doe@example.com
• news:comp.infosystems.www.servers.unix
• tel:+1-816-555-1212
• urn:oasis:names:specification:docbook:dtd:xml:4.1.2

E URLs são esses exemplos:

• ftp://ftp.is.co.za/rfc/rfc1808.txt
• http://www.ietf.org/rfc/rfc3986.txt
• ldap://[2001:db8::7]/c=GB?objectClass?one
• telnet://192.0.2.16:80/

Pode-se deduzir que são bastante distintas na sintaxe.

URL tem "protocolo://", onde protocolo é http, ftp, gopher, etc, mas tem também o URL abreviado (veremos adiante) que não tem o scheme e a authority.

URN segue a sintaxe urn:algo:mais_algo:etc.

Veja essa imagem tirada da rfc3986: Vejam que está bem distinto na imagem:

• foo://example.com:8042/over/there?name=ferret#nose é um URL.
• urn:example:animal:ferret:nose é um URN.

E os dois são URIs.

E a parte "name=ferret#nose" é o URN dentro do URL e a linha toda é um URI.

Seguindo no exemplo "https://www.vivaolinux.com.br/busca/?cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster" temos que, com certeza, a linha completa é um URI.

A URL pode ser a parte "https://www.vivaolinux.com.br/busca/", pode ser também o URL abreviado "/busca/?cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster" e pode ser também toda a linha; e neste caso não temos URN... pelo menos é o que eu acho.

Na página da rfc1630 temos o seguinte:

"This document is available in hypertext form at:

http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html"

E mais adiante:

"URLs

For existing Internet access protocols, it is necessary in most cases to define the encoding of the access algorithm into something concise enough to be termed address. URIs which refer to objects accessed with existing protocols are known as "Uniform Resource Locators" (URLs) and are listed here as used in WWW, but to be formally defined in a separate document."

Nos interessa a última parte:

"URIs que se referem a objetos acessados com protocolos existentes são conhecidos como "Uniform Resource Locators" (URLs) e são listados aqui como usados na WWW, mas devem ser formalmente definidos em um documento separado."

Está bem claro que o protocolo (http, ftp, etc) faz parte daquilo que se entende por URL.

Daí você clica no link oferecido na RFC para acessar em hipertexto e cai na página:


Onde se pode ver que o servidor web utilizado (não saberia precisar qual) diz que o URL requisitado é a parte "/hypertext/WWW/Addressing/URL/URI_Overview.html", ou seja, não tem o protocolo http:// (Scheme) e info.cern.ch (Authority) na sequência de caracteres.

E pelo que se entende até agora das RFCs o correto seria:


Porém, a rfc2396 na seção F, fala de URLs abreviados:

"A sintaxe do URL foi projetada para referência inequívoca a recursos de rede e extensibilidade por meio do esquema de URL. No entanto, à medida que a identificação e utilização de URL se tornaram comuns, os meios de comunicação tradicionais (televisão, rádio, jornais, outdoors, etc.) têm utilizado cada vez mais referências de URL abreviados.

URLs abreviados são uma referência que consiste apenas nas partes de autoridade (Authority) e caminho (Path) do recurso identificado, como www.w3.org/Addressing/ ou simplesmente o nome do host DNS por si só. Essas referências destinam-se principalmente à interpretação humana e não à máquina, com a suposição de que a heurística baseada no contexto é suficiente para completar o URL (por exemplo, a maioria dos nomes de host que começam com "www" provavelmente terá um prefixo de URL "http://").

Embora não exista um conjunto padrão de heurísticas para desambiguar referências de URL abreviados, muitas implementações de clientes permitem que eles sejam inseridos pelo usuário e resolvidos heuristicamente. Deve-se notar que tais heurísticas podem mudar ao longo do tempo, particularmente quando novos esquemas de URL são introduzidos.

Como um URL abreviado tem a mesma sintaxe de um caminho de URL relativo, as referências de URLs abreviados não podem ser usadas em contextos onde são esperados URLs relativos. Isso limita o uso de URLs abreviados a locais onde não há URL base definido, como caixas de diálogo e anúncios off-line."

Entretanto, a rfc2396 foi substituída pela rfc3986 que não fala nada sobre URLs abreviados, mas URLs abreviados continuam sendo largamente utilizados. Lembram no início do artigo onde foi citado que a Request-URI às vezes pode ser o URL abraviado... pois então, este é um caso. A Request-URI é um URL abreviado.

Resumindo, pode ser tanto:

"The requested URL /hypertext/WWW/Addressing/URL/URI_Overview.html was not found on this server."

quanto:

"The requested URL http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html was not found on this server."

As duas formas estão corretas.

Em suma, posso dizer basicamente que um link para um site é um URL; um endereço de e-mail é um URN quando tem "mailto:" antes; e os dois são URIs. "mailto" também é um esquema de URL que designa um "recurso da Internet", que é a caixa de correio especificada no endereço, no caso, não é um protocolo, é um atributo de protocolo, é um esquema (scheme) de URL (rfc2368). Um "scheme" pode ou não ser um protocolo e "mailto" pode ser um protocolo também, dependendo de como e quando for utilizado.

O URL e o URN diferem basicamente na sintaxe, na forma como são escritos, mas os dois são URIs.

Faça o teste e digite na barra de endereços do seu navegador: mailto:seu_e-mail@email.com

onde seu_e-mail@email.com você troca pelo seu e-mail.

• No Windows abrirá o Outlook.
• No Linux abrirá uma janela pedindo para você escolher um aplicativo de e-mail.

"mailto:seu_e-mail@email.com" na barra de endereços é um URN, sendo que a parte "email.com" é um URL.

Porém, a rfc2368 também diz que isso abaixo é um URL (mailto URL): mailto:infobot@example.com?body=send%20current-issue%0D%0Asend%20index

E isso também: mailto:chris@example.com

RESUMO

URI é um termo genérico, é uma forma generalizada de denominar tanto URLs quanto URNs. As RFCs aconselham chamar tudo de URI para evitar confusão.

As RFCs (Request for Comments - Pedido/Requisição para Comentários), na esmagadora maioria dos casos, são somente sugestões e não regras obrigatórias.

A coisa parece confusa, pois envolve conceitos, nomes e coisas reais, mas é só abstrair (decompor em partes) e partir de onde se está para daí então fazer as comparações, por exemplo, o conceito de "non-networked" citado antes: o computador em relação a uma rede interna e a um recurso buscado dentro do próprio computador é "non-networked" e a rede interna em relação a uma rede externa é "non-networked" e uma rede externa em relação a "world wide web" é "non-networked".

Para fins de entendimento, "Solicitação" é o URI, é a sequência completa de caracteres e "Requisição" é a Request-URI. A Request-URI está dentro do URI.

As informações acima mais detalhadas você encontra no link das RFCs nas referências no final. Aconselho ao estimado leitor, caso tenha chegado até essa parte do texto: divirta-se tentando destrinchar o calhamaço de RFCs!

Vou logo avisando: você ficará horas lendo RFCs inteiras e saltando de uma RFC para outra feito um coelho.

É uma tarefa para presidiário.

Outra pergunta que pode surgir é: POR QUÊ?

A resposta é que fiz isso aos poucos fazendo anotações quando estava trabalhando num site; e a poucas semanas atrás, consultando meus alfarrábios desapercebidamente encontrei este texto, cujo nem lembrava mais e resolvi repaginá-lo para publicação.