En reprenant mes « vieux » diaporamas sur les identifiants, je me rends compte que j’ai contribué à propager des idées fausses sur les URL et les URI, belles métaphores à l’appui, notamment en proclamant que « une URI est la combinaison d’un nom et d’une localisation » ce qui a pu être compris un peu vite comme « URI=URL+URN ».

Je fais amende honorable en proclamant ici que les URL sont des URI.
Les URN aussi sont des URI, la seule chose de particulier qu’elles ont, c’est qu’elles commencent par « urn: ».

Il faut se débarrasser de la vieille idée reçue que les URL correspondent à une localisation d’un fichier sur un serveur. C’est de moins en moins souvent le cas sur le Web aujourd’hui. Les URL générées par les outils de gestion de contenu, par exemple, sont en fait des paramètres qui permettent de dire au logiciel comment accéder à la ressource.

Une URL, c’est donc
– une URI (parce qu’elle en respecte la syntaxe)
– qui commence (en général) par « http: » (qui est un préfixe d’URI enregistré et donc reconnu)
– qui identifie une ressource principalement par le mécanisme qui permet d’y accéder (par exemple, son emplacement sur le réseau).

Ce mécanisme peut être le nom du fichier et son emplacement sur le serveur.
Il peut être aussi une série de paramètres qui appellent une base de donnée, via un logiciel.
Ou une chaîne de caractères qui va être interprétée grâce à un annuaire qui « sait » où se trouve la ressource en question.

En conséquence de quoi, les URL sont des URI et peuvent prétendre à la pérennité, autant que n’importe quel autre type d’URI, pour un peu qu’on les gère correctement.

Les rapports et différences entre URI, URL et URN sont expliqués dans la RFC 3305.