Loading

NOM

       uri,  url, urn - Identificateur de ressource uniforme (URI), comprenant
       URL ou URN

SYNOPSIS

       URI = [ URI_absolu | URI_relatif ] [ "#" fragment ]

       URI_absolu = mécanisme ":" ( partie_hiérarchique | partie_opaque )

       URI_relatif = ( chemin_réseau | chemin_absolu | chemin_relatif )
                       [ "?" requête ]

       mécanisme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
                    "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

       partie_hierarchique = ( chemin_réseau | chemin_absolu ) [ "?" requête ]

       chemin_réseau = "//" autorité [ chemin_absolu ]

       chemin_absolu = "/"  segments_chemin

       chemin_relatif = segment_relatif [ chemin_relatif ]

       Un Identificateur de Ressource Uniforme (URI) est une courte chaîne  de
       caractères identifiant une ressource physique ou abstraite (par exemple
       une page web). Une Localisation de Ressource Uniforme (URL) est un  URI
       qui   identifie   une   ressource  à  travers  son  moyen  d’accès  (sa
       « position » réseau par exemple), plutôt que par son nom  ou  un  autre
       attribut de la ressource. Un Nom de Ressource Uniforme (URN) est un URI
       qui doit rester globalement unique, et persister même si  la  ressource
       cesse d’exister ou devient indisponible.

       Les  URI constituent le mécanisme standard pour nommer les destinations
       des liens hypertextes pour les outils comme  les  navigateurs  web.  La
       chaîne  «http://www.kernelnotes.org »  est  une  URL  (et donc aussi un
       URI). Beaucoup de gens utilisent le terme URL comme vague  synonyme  de
       URI (bien que techniquement les URL soient un sous-ensemble des URI).

       Les  URI  peuvent  être  absolus  ou relatifs. Un identificateur absolu
       référence  une  ressource  indépendamment  du  contexte,  alors   qu’un
       identificateur   relatif   référence  une  ressource  en  décrivant  la
       différence par rapport au contexte  courant.  Dans  les  références  de
       chemins  relatifs,  les  segments  complets  «. »  et  « .. »  ont  des
       significations particulières : « le niveau actuel dans la  hiérarchie »
       et  « le  niveau  au-dessus  dans la hiérarchie », respectivement, tout
       comme dans les systèmes type Unix. Un segment de chemin qui contient un
       caractère deux-points ne peut pas être utilisé comme premier segment du
       chemin d’un URI (par exemple « ceci:cela »), car on le confondrait avec
       le   mécanisme.   Précédez   un   tel  segment  avec  ./  (par  exemple
       « ./ceci:cela »). Notez que les descendants de MS-DOS (par ex. Windows)
       remplacent  le  deux-points  du  nom  de  périphérique  par  une  barre
       verticale dans les URI, ainsi « C: » devient "C| ».

       Un identificateur de fragment, s’il est présent, référence une  portion
       particulière  de  la  ressource ;  le texte après le « # » identifie le
       fragment. Un URI commençant par « # » référence  le  fragment  dans  la
       ressource courante.

   Utilisation
       Il  y  a plusieurs schémas d’URI différents, chacun ajoutant des règles
       et des significations spécifiques, mais ils sont volontairement  rendus
       le  plus  ressemblants  possible.  Par exemple, plusieurs schémas d’URL
       permettent le  format  suivant  pour  décrire  l’autorité  d’un  chemin
       réseau,  que  l’on  appellera  serveur_ip  (les  crochets encadrent les
       parties optionnelles) :

       serveur_ip = [user [ : password ] @ ] hte [ : port]

       Ce format permet d’insérer éventuellement un nom  d’utilisateur,  suivi
       éventuellement  d’un  mot  de passe, et/ou un numéro de port. La partie
       hte est le nom de l’ordinateur, soit son nom  déterminé  par  le  DNS,
       soit  son  adresse  IP  (numéros  séparés  par des points). Ainsi l’URI
       <http://fred:fredpassword@xyz.com:8080/> se connecte  dans  le  serveur
       web  sur  l’ordinateur xyz.com avec l’identité fred (et le mot de passe
       fredpassword) en utilisant le port 8080. Évitez d’utiliser les mots  de
       passe  dans  les  URI  à cause des risques liés à la sécurité sitôt que
       l’on écrit un mot de passe. Si l’URL indique un  nom  d’utilisateur  et
       pas  de mot de passe, et si le serveur distant réclame un mot de passe,
       alors  le  programme  interprétant  l’URL  peut  en   demander   un   à
       l’utilisateur.

       Voici  les  mécanismes les plus courants utilisés sur les systèmes type
       Unix, compris par de  nombreux  outils.  Notez  que  beaucoup  d’outils
       gérant les URI ont aussi des mécanismes internes ou spécialisés ; voyez
       la documentation de ces outils pour plus de détails.

       http - Serveur Web (HTTP)

       http://serveur_ip/chemin
       http://serveur_ip/chemin?requte

       Il s’agit d’une URL accédant à un  serveur  web  (HTTP).  Le  port  par
       défaut  est  80.  Si  le  chemin  référence  un  répertoire, le serveur
       choisira  ce  qu’il  renverra.  Habituellement,  si  un  fichier  nommé
       « index.html »  ou  «index.htm »  est présent, son contenu est renvoyé.
       Sinon, il crée et renvoie une liste des fichiers dans le répertoire  en
       cours avec les liens appropriés. Un exemple : <http://lwn.net>.

       Une  requête  peut  être formulée dans le format archaïque « isindex »,
       consistant en mot ou phrase sans signe égal  « = ».  Une  requête  peut
       aussi  être  dans  le  format « GET » plus long, qui a une ou plusieurs
       entrées de requêtes de la forme cl=valeur séparées  par  un  caractère
       « et  commercial »  « & ». Notez que la cl peut être répétée plusieurs
       fois, et  c’est  au  serveur  web  et  ses  programmes  applicatifs  de
       déterminer s’il y a une signification pour cela. Il y a une interaction
       malheureuse avec HTML/XML/SGML et le format de requête GET.  Quand  une
       telle requête avec plusieurs clés est incluse dans un document SGML/XML
       (y compris HTML), le «et commercial »  « & »  doit  être  réécrit  sous
       forme  « &amp; ».  Notez  que  toutes  les  requêtes n’utilisent pas ce
       format ; elles peuvent être trop longues pour être stockée  en  URL  et
       utilisent  un  mécanisme  d’interaction  différent  (appelé  POST) sans
       inclure les données dans l’URI. Voir la  spécification  Common  Gateway
       Interface  (CGI)  à  l’adresse  <http://www.w3.org/CGI>  pour  plus  de
       détails.

       ftp - File Transfer Protocol (FTP)

       ftp://serveur_ip/chemin

       Cette URL accède à un fichier à travers le protocole FTP. Le  port  par
       défaut  (pour  les  commandes) est 21. Si aucun nom d’utilisateur n’est
       inclus, l’utilisateur « anonymous » est employé,  et  dans  ce  cas  de
       nombreux  clients  fournissent l’adresse courriel du requérant en guise
       de mot de passe. Un exemple est <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

       gopher - Serveur Gopher

       gopher://serveur_ip/type_gopher slecteur
       gopher://serveur_ip/type_gopher slecteur%09recherche
       gopher://serveur_ip/type_gopher slecteur%09recherche%09chaine_gopher+

       Le port gopher par défaut est 70. Le type_gopher est un  champ  composé
       d’un  unique caractère indiquant le type de ressource Gopher à laquelle
       l’URL fait référence. Le chemin entier paut aussi être vide, auquel cas
       le  délimiteur  « / »  est  aussi  optionnel et le type_gopher prend la
       valeur par défaut « 1 ».

       selecteur est une chaîne de sélecteur Gopher. Dans le protocole Gopher,
       la  chaîne de sélecteur est une séquence d’octets pouvant contenir tous
       les octets sauf 09 hexadécimal (HT Ascii ou Tabulation), 0A hexadécimal
       (LF Ascii), et 0D (CR Ascii).

       mailto - Adresse courriel

       mailto:adresse-courriel

       Il s’agit d’une adresse courriel, en principe de la forme nom@nom_hte.
       Voir mailaddr(7) pour plus d’informations sur le format  correct  d’une
       adresse  courriel.  Notez que les caractères % doivent être transformés
       en %25. Un exemple : <mailto:dwheeler@dwheeler.com>.

       news - Groupe ou message des news

       news:nom-groupe-news
       news:id-message

       Un nom-groupe-news est un nom hiérarchique  délimité  par  des  points,
       comme   « comp.infosystems.www.misc ».  Si  nom-groupe-news  est  « * »
       (comme  dans  <news:*>),  l’URL  référence  tous   les   groupes   news
       disponibles. Un exemple : <news:comp.lang.ada>.

       Un  id-message  correspond  au  champ  identificant  Message-ID de IETF
       RFC 1036, sans  les  chevrons  « < »  et  « > » ;  il  prend  la  forme
       unique@nom-domaine-complet.  Un  identificateur  de  message  peut être
       distingué d’un nom de groupe de  news  par  la  présence  du  caractère
       « @ ».

       telnet - Connexion telnet

       telnet://serveur_ip/

       Le  mécanisme  d’URL  Telnet  est  utilisé  pour  afficher  un  service
       interactif accessible par le protocole Telnet. Le caractère « / » final
       peut   être   omis.   Le   port   par   défaut  est  23.  Un  exemple :
       <telnet://melvyl.ucop.edu/>.

       file - Fichier normal

       file://serveur_ip/segments_chemins
       file:segments_chemins

       Ceci représente un fichier ou un répertoire accessible  localement.  En
       particulier, hte peut être la chaîne « localhost » ou une chaîne vide;
       elle est interprétée comme « la machine sur laquelle l’URL est en cours
       d’interprétation ». Si le chemin conduit à un répertoire, le navigateur
       devrait afficher le contenu du répertoire avec des  liens  pour  chaque
       élément.  Tous  les  navigateurs  ne  le  font pas encore. KDE prend en
       charge les fichiers générés par l’URL <file:/cgi-bin>.  Si  le  fichier
       n’est  pas trouvé, l’analyseur du navigateur peut essayer de développer
       le nom du fichier (voir glob(7) et glob(3)).

       Le second format (par ex. <file:/etc/passwd>)  est  le  format  correct
       pour référencer un fichier local. Toutefois les anciens standards ne le
       permettaient pas, et certains programmes ne le reconnaissent pas  comme
       URI.  Une syntaxe plus portable est d’utiliser une chaîne vide en guise
       de nom de serveur <file:///etc/passwd> ; cette forme a le même effet et
       est  reconnue  facilement  comme  un URI par les analyseurs des anciens
       programmes. Notez que si vous  désirez  vraiment  écrire  « débuter  de
       l’emplacement  actuel »,  n’indiquez  pas  de  mécanisme ; utilisez une
       adresse  relative  comme  <../test.txt>,  qui   est   indépendante   du
       mécanisme. Un exemple de ce mécanisme est <file:///etc/passwd>.

       man - Pages de manuel

       man:nom-commande
       man:nom-commande(section)

       Ceci  référence  les  pages de documentation en ligne (man) locales. Le
       nom de la commande peut être suivi  éventuellement  de  parenthèses  et
       d’un  numéro de section. Voir man(7) pour plus de renseignements sur la
       signification du numéro de section. Ce mécanisme d’URI est  unique  aux
       systèmes  Unix (comme Linux) et n’est pas encore enregistré par l’IETF.
       Un exemple : <man:ls(1)>.

       info - Page de documentation Info

       info:nom-de-fichier-virtuel
       info:nom-de-fichier-virtuel#nom-de-noeud
       info:(nom-de-fichier-virtuel)
       info:(nom-de-fichier-virtuel)nom-de-noeud

       Ce mécanisme référence les pages de documentation en-ligne info (créées
       par  les  fichiers  texinfo),  un format utilisé par les outils GNU. Ce
       mécanisme est spécifique aux systèmes Unix (comme Linux) et  n’est  pas
       encore enregistré par l’IETF. Actuellement, Gnome et Kde divergent dans
       la syntaxe d’URI et chacun rejete  la  syntaxe  de  l’autre.  Les  deux
       premiers  formats  sont  ceux de Gnome ; dans le nom de noeud, tous les
       espaces sont remplacés par des soulignés.  Les  deux  formats  suivants
       sont ceux de Kde ; les espaces doivent rester tels quels, même si c’est
       interdit dans les standards d’URI. On peut espérer que dans l’avenir la
       plupart  des  outils  comprendront  les deux formats et accepteront des
       soulignés en remplacement des espaces. Dans tous  les  cas,  le  format
       sans  nom  de  noeud  est  supposé viser le noeud « Top »". Exemples de
       format Gnome : <info:gcc> et <info:gcc#G++_and_GCC>. Exemples de format
       Kde : <info:(gcc)> et <info:(gcc)G++ and GCC>.

       whatis - Recherche de documentation

       whatis:chane

       Ce  mécanisme  parcourt  une  base  de  données  de courtes (une ligne)
       descriptions des  commandes  et  renvoie  une  liste  des  descriptions
       contenant  la  chaîne. Seules les correspondances de mots complets sont
       renvoyées. Voir whatis(1). Ce mécanisme est unique  aux  systèmes  Unix
       (comme Linux) et n’est pas encore enregistré par l’IETF.

       ghelp - Documentation daide Gnome

       ghelp:nom-application

       Ceci  charge la documentation d’aide Gnome pour l’application indiquée.
       Notez qu’il n’y a pas encore beaucoup de documentation dans ce  format.

       ldap - Lightweight Directory Access Protocol

       ldap://hostport
       ldap://hostport/
       ldap://hostport/dn
       ldap://hostport/dn?attributs
       ldap://hostport/dn?attributs?porte
       ldap://hostport/dn?attributs?porte?filtre
       ldap://hostport/dn?attributs?porte?filtre?extensions

       Ce  mécanisme  prend  en  charge  les  requêtes  utilisant le protocole
       Lightweight  Directory  Access  Protocol  (LDAP),  pour  interroger  un
       ensemble    de    serveurs    à    propos   d’informations   organisées
       hiérarchiquement (comme des gens ou  des  ressources  de  calcul).  Des
       informations   supplémentaires  sur  les  mécanismes  d’URL  LDAP  sont
       disponibles dans la RFC 2255 : Les composants de l’URL sont :

       hostport    le serveur LDAP à interroger, écrit  comme  un  nom  d’hôte
                   suivi  éventuellement  par  un  deux-points et un numéro de
                   port. Le port TCP pour le LDAP est 389. Si le nom est vide,
                   le client détermine le serveur LDAP à utiliser.

       dn          Le  nom  complet  (Distinguished  Name) LDAP, qui identifie
                   l’objet de base de la recherche LDAP (voir RFC 2253 section
                   3).

       attributs   une liste d’attributs à renvoyer séparés par des virgules ;
                   voir  la  RFC2251  section  4.1.5.  Par  défaut  tous   les
                   attributs sont renvoyés..

       portée      indique  la  portée  de la recherche qui peut être « base »
                   (recherche d’objet de  base),  « one »  (recherche  sur  un
                   niveau),  ou  « sub »  (recherche  dans un sous-arbre). Par
                   défaut, on considère « base ».

       filtre      indique le filtre de recherche (sous-ensemble des entrées à
                   renvoyer).  Par  défaut, toutes les entrées sont renvoyées.
                   Voir RFC 2254 section 4.

       extensions  une liste de paires type=valeur séparées par des  virgules,
                   où  la  portion =valeur peut être omise pour les options ne
                   la nécessitant pas. Une extension préfixée par un « ! » est
                   critique (doit être pris en charge pour être valide), sinon
                   elle est non-critique (facultative).

       Les requêtes LDAP sont plus faciles à comprendre par  l’exemple.  Voici
       une requête demandant à ldap.itd.umich.edu des informations à propos de
       l’Université du Michigan aux U.S. :

       ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

       Pour n’obtenir que l’attribut Adresse Postale, on demanderait :

       ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

       Pour demander à host.com, sur le port  6666  des  informations  sur  la
       personne  de  nom  courant  (cn)  « Babs  Jensen »  à  l’University  du
       Michigan, demandez:

       ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

       wais - Wide Area Information Servers

       wais://hostport/base
       wais://hostport/base?recherche
       wais://hostport/base/wtype/wpath

       Ce mécanisme désigne une base de données  WAIS,  une  recherche  ou  un
       document  (voir  IETF  RFC 1625  pour plus de renseignements sur WAIS).
       Hostport est le nom d’hôte, suivi éventuellement  d’un  deux-points  et
       d’un numéro de port (par défaut 210).

       La première forme désigne une base de données WAIS pour les recherches.
       La seconde  désigne  une  recherche  particulière  dans  la  base  WAIS
       indiquée.   La  troisième  forme  désigne  un  document  particulier  à
       retrouver dans la base de données WAIS. wtype est la  désignation  WAIS
       du type d’objet et wpath est l’identificateur WAIS du document.

       Autres mécanismes

       Il  existe  d’autres mécanismes URI. La plupart des outils traitant les
       URI acceptent  un  jeu  d’URI  internes  (par  exemple,  Mozilla  a  un
       mécanisme  about:  pour  les  informations  internes,  et le navigateur
       d’aide Gnome a un mécanisme toc: pour diverses opérations). Il y  a  de
       nombreux  mécanismes  qui  ont  été définis mais pas très utilisés pour
       l’instant (par exemple, prospero). Le mécanisme nntp:  est  déconseillé
       en  faveur  de  celui  news:.  Les  URN  seront prises en charge par le
       mécanisme  urn:  avec  des  espaces  de  noms   hiérarchique   (p.ex. :
       urn:ietf:...  pour les documents IETF). Pour le moment, les URN ne sont
       pas très largement implémentés. Tous les outils ne gèrent pas tous  les
       mécanismes.

   Codage des caractères
       Les  URI utilisent un nombre limité de caractères afin d’être saisis et
       utilisés dans de nombreuses situations.

       Les caractères suivants sont réservés ; ils peuvent apparaître dans  un
       URI,  mais  leurs usages est limités aux fonctionnalités réservées (les
       données conflictuelles doivent être protégées avant de former l’URI) :

                 ; / ? : @ & = + $ ,

       Les caractères non-réservés  peuvent  être  inclus  dans  un  URI.  Les
       caractères   non-réservés   incluent   les   majuscules  et  minuscules
       anglaises, les chiffres décimaux, et l’ensemble suivant  de  signes  de
       ponctuation et de symboles :

               - _ . ! ~ * ’ ( )

       Tous  les autres caractères doivent être protégés. Un octet protégé est
       encodé sous forme d’un triplet de caractères, consistant  en  un  signe
       pourcent « % » suivi de deux chiffres hexadécimaux représentant le code
       de l’octet (les lettres hexadécimales peuvent être en majuscules ou  en
       minuscules).  Par  exemple un espace blanc doit être protégé sous forme
       «%20 », une tabulation  « %09 »  et  le  « & »  en  « %26 ».  Comme  le
       caractère  "% »"  a  toujours  un rôle réservé pour protéger les autres
       caractères, il faut le protéger sous forme « %25 ». Il est  courant  de
       protéger  le  caractère espace en symbole plus « + » dans les requêtes.
       Cette  pratique  n’est   pas   défini   uniformément   dans   les   RFC
       correspondantes  (qui  recommandent  %20  plutôt)  mais tous les outils
       acceptant les URI avec  des  requêtes  préparées  ainsi.  Une  URI  est
       toujours montrée dans sa forme protégée.

       Les  caractères  non-réservés  peuvent  être  protégés sans modifier la
       sémantique de l’URI, mais il faut l’éviter sauf si  l’URI  est  utilisé
       dans  un  contexte  qui  ne  permet  pas l’utilisation du caractère non
       protégé. Par exemple « %7E » est parfois utilisé à la  place  de  « ~ »
       dans  les  URL  HTTP  mais les deux sont en réalité équivalents dans ce
       contexte.

       Pour les URI qui doivent manipuler des caractères hors du jeu ASCII, la
       spécification  HTML  4.01  (section B.2) et la RFC 2718 (section 2.2.5)
       préconisent l’approche suivante :

       1.  traduire le caractère en séquence UTF-8 (RFC 2279) — voir  utf-8(7)
           — puis

       2.  utiliser  le  mécanisme d’échappement d’URI, c’est-à-dire, utiliser
           les %HH pour coder les octets non-sûrs.

   Écrire un URI
       Lorsqu’il  est  écrit,  un  URI  doit  être  placé   entre   guillemets
       ("http://www.kernelnotes.org"),     encadré     par     des    chevrons
       (<http://lwn.net>),  ou  placé   sur   une   ligne   indépendante.   Un
       avertissement  à  propos  des  guillemets :  Ne  jamais  introduire une
       ponctuation supplémentaire (comme le point final  d’une  phrase  ou  la
       virgule  séparant les éléments d’une liste) à l’intérieur de l’URI, car
       cela modifierait sa valeur. [Ndt : cet avertissement vaut surtout  pour
       les  anglo-saxons ;  en  français  l’usage  veut  que  les  éléments de
       ponctuations restent à l’extérieur des guillemets.]  On  peut  utiliser
       les  chevrons  à  la  place, ou basculer sur un système de notation qui
       n’incopore aucun caractère supplémentaire à l’intérieur des marques  de
       citation.   Ce  système  [Ndt :  le  nôtre !],  appelé  « nouveau »  ou
       « logique » par les « Hart’s Rules » et  le  « Oxford  Dictionnary  for
       Writes  and  Editors »,  est  la  pratique préférée des hackers dans le
       monde entier. Voir la section sur le style d’écriture  dans  le  Jargon
       File  (http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html pour
       plus de détails. Les documentations anciennes  suggèrent  d’insérer  le
       préfixe  «URL: »  juste  avant  un URI, mais cette forme n’a jamais été
       utilisée réellement.

       La syntaxe des URI a été conçue pour éviter les ambiguïtés.  Toutefois,
       comme  les  URI  sont  devenus  de  plus  en  plus répandus, les médias
       traditionnels télévision, radio, journaux et magazines...) ont  utilisé
       de  manière  croissante  des abréviations d’URI, consistant en la seule
       partie autorité et segments de chemin  de  la  ressource  (par  exemple
       <www.w3.org/Addressing>).  De tels références sont surtout prévues pour
       une interprétation humaine, avec la supposition que la compréhension du
       contexte  permet  de  compléter  l’URI  (par  exemple  les noms d’hôtes
       commençant par « www »  se  préfixent  avec  « http:// »  et  les  noms
       commençant par «ftp » doivent se préfixer avec « ftp:// »). De nombreux
       clients résolvent ces références  avec  de  telles  heuristiques.  Elle
       peuvent   toutefois   évoluer,   particulièrement   quand  de  nouveaux
       mécanismes sont introduits. Comme les URI abrégés ont la  même  syntaxe
       qu’un  chemin  d’URL  relative,  les  références  abrégées  ne sont pas
       utilisables lorsque des URI relatifs  sont  autorisés.  N’utilisez  pas
       d’URI  abrégés  comme  liens  hypertexte dans un document ; utilisez le
       format standard décrit ici.

CONFORMITÉ

       http://www.ietf.org/rfc/rfc2396.txt          (IETF           RFC 2396),
       http://www.w3.org/TR/REC-html40 (HTML 4.0).

NOTES

       Un  outil  acceptant  les  URI  (par  exemple un navigateur web) sur un
       système  Linux  devrait  être  capable  de  traiter   (directement   ou
       indirectement)  tous  les  mécanismes  décrits  ici,  y compris man: et
       info:. Sous-traiter ces éléments à un autre programme est tout  à  fait
       acceptable, et même encouragé.

       Techniquement, la notation d’un fragment ne fait pas partie de l’URI.

       Pour  savoir  comment  incorporer  des  URI (y compris des URL) dans un
       format de données, voir la documentation sur ce format. HTML utilise le
       format  <A  HREF="uri">  text  </A>.  Les fichiers texinfo utilisent le
       format @uref{uri}. Man et mdoc ont une macro UR récemment  ajoutée,  ou
       incluent  juste  l’URI dans le texte (les visualiseurs doivent détecter
       le :// comme portion d’URI).

       Les environnements Gnome et Kde  divergent  actuellement  sur  les  URI
       qu’ils  acceptent,  en  particulier  dans  leurs  systèmes d’aide. Pour
       lister les pages de manuel,  Gnome  utilise  <toc:man>  alors  que  Kde
       utilise  <man:(index)>.  Pour  lister  les  pages  info,  Gnome emploie
       <toc:info>  et  Kde  <info:(dir)>  (l’auteur  de  cette  page   préfère
       l’approche   Kde,   bien  qu’un  format  plus  régulier  serait  encore
       meilleur). En général, Kde utilise <file:/cgi-bin/> comme préfixe  pour
       les  fichiers générés. Kde préfère la documentation en Html, accessible
       avec <file:/cgi-bin/helpindex>. Gnome préfère le mécanisme  ghelp  pour
       stocker  et  retrouver  la  documentation. Aucun navigateur ne gère les
       références file: vers un répertoire à l’heure où j’écris ces lignes, ce
       qui rend difficile de se référer à un répertoire avec un URI navigable.
       Comme indiqué plus haut, ces environnements diffèrent sur la gestion du
       mécanisme  info:,  probablement  leur  plus  importante  divergence. On
       espère que Gnome et Kde vont converger vers des formats d’URI  communs,
       et  la  future  version  de  cette  page  décrira  le résultat de cette
       convergence.

   Sécurité
       Un URI ne pose pas de problème de  sécurité  par  lui-même.  Il  n’y  a
       aucune  garantie  qu’une  URL,  qui  localise une ressource à un moment
       donné continuera de le faire. Pas plus qu’il n’y a de  garantie  qu’une
       URL  ne  localisera pas une ressource différente à un autre moment. Les
       seules garanties peuvent être fournies par  les  personnes  qui  gèrent
       l’espace de noms de la ressource en question.

       Il  est  parfois  possible  de  construire  une  URL  de manière qu’une
       tentative de réaliser une opération apparemment bénigne, comme  accéder
       à   la   ressource   associée,   va  en  réalité  produire  une  action
       éventuellement dommageable pour le correspondant.  Les  URL  non  sûres
       sont  typiquement construites en indiquant un numéro de port différents
       de ceux réservés pour les protocoles en question.  Le  client,  croyant
       contacter un site, va en réalité engager un autre protocole. Le contenu
       de l’URL  contient  des  instructions,  qui  interprétées  par  l’autre
       protocole,  produisent  des  résultats  inattendus.  Un  exemple  a été
       l’emploi d’une URL Gopher pour envoyer un message falsifié et  indésiré
       sur un serveur SMTP.

       Il faut être prudent en utilisant une URL qui indique un numéro de port
       différent de celui du protocole, particulièrement si ce numéro est dans
       l’espace réservé.

       Il  faut  s’assurer que lorsque l’URI contient des délimiteurs protégés
       pour un protocole donné (par exemple CR et LF pour le protocole telnet)
       qu’ils  ne  soient  pas « déprotégés » avant la transmission. Ceci peut
       violer le protocole, mais évite le risque que ces caractères servent  à
       simuler  une  opération  dans  ce protocole, ce qui peut conduire à des
       actions distantes éventuellement nocives.

       Il est clairement déraisonnable d’utiliser un URI qui contient  un  mot
       de  passe  censé  être  secret. En particulier, l’utilisation du mot de
       passe dans la  partie  « info  utilisateur »  de  l’URI  est  fortement
       déconseillé,  sauf s’il s’agit d’un de ces cas rares où le mot de passe
       est vraiment public.

BOGUES

       La documentation peut se trouver dans un grand nombre d’endroit,  ainsi
       il  n’y  a  pas  encore  de  bon  mécanisme d’URI pour la documentation
       générale en-ligne, dans des formats arbitraires. Les  référence  de  la
       forme   <file:///usr/doc/ZZZ>  ne  fonctionnent  pas,  car  différentes
       distributions et installations locales peuvent placer les fichiers dans
       divers  répertoires  (cela  peut  être  /usr/doc, ou /usr/local/doc, ou
       /usr/share, ou autre part).  De  même,  le  répertoire  ZZZ  change  en
       principe  avec le numéro de version (bien que le développement des noms
       de fichiers puisse  partiellement  couvrir  ce  problème).  Finalement,
       l’utilisation  du  mécanisme  file: n’est pas recommandée pour les gens
       qui consultent la documentation dynamiquement  depuis  Internet  plutôt
       que  de la télécharger sur leur système de fichiers local. Un mécanisme
       d’URI sera peut être ajouté dans l’avenir (p.ex. :  « userdoc: »)  pour
       permettre   aux   programme   d’inclure   des  références  vers  de  la
       documentation plus détaillées  sans  avoir  à  connaître  l’emplacement
       exact  de celle-ci. Autrement, une version future des spécifications du
       système  de  fichiers  peut  décrire  les   emplacements   de   manière
       suffisamment précise pour que le mécanisme file: soit capable de situer
       la documentation.

       De nombreux programmes et formats de fichiers n’incluent aucune manière
       d’incorporer ou l’implémenter des liens utilisant les URI.

       Beaucoup   de   programmes   ne  traitent  pas  tous  les  formats  URI
       différents ; il devrait y avoir un mécanisme standard pour  charger  un
       URI  quelconque qui détecte automatiquement l’environnement utilisateur
       (p.ex. : texte ou graphique, environnement de  bureau,  préférences  de
       l’utilisateur,  outils  en  cours  d’exécution) et invoque le bon outil
       quelque soit l’URI.

VOIR AUSSI

       lynx(1), man2html(1), mailaddr(7), utf-8(7), IETF RFC 2255

COLOPHON

       Cette page fait partie de  la  publication  3.23  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      être       trouvées       à       l’adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Cette  page  de  manuel  a  été  traduite et mise à jour par Christophe
       Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis  par
       Alain  Portal  <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

       Veuillez  signaler  toute  erreur   de   traduction   en   écrivant   à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document
       en utilisant la commande « man -L C <section> <page_de_man> ».