Provided by: manpages-fr_1.67.0-1_all bug

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 ]

DESCRIPTION

       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 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.

USAGE

       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.  Evitez 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épararé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 email 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 Email
       mailto:adresse-email

       Il  s’agit  d’une  adresse email, en principe de la forme nom@nom_hte.
       Voir mailaddr(7) pour plus d’informations sur le format  correct  d’une
       adresse  email.  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 identificateur Message-ID de la RFC
       1036 de l’IETF 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 supporte 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  à  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écanimse 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  supporte 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 séparés par des virgule à renvoyer ;
                   voir la  RFC  2251  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 supportée 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 supportés par le mécanisme urn: avec
       des espaces de noms hierarchique (ex : urn:ietf:... pour les  documents
       IETF).  Pour le moment, les URN ne sont pas très largement implémentés.
       Touts les outils ne supportent 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 appararaî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 poté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,
       les  spécifications  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    chevronss
       (<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  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  clents
       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.

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èe 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.

SECURITÉ

       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é contiuera 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ère
       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 apparement 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.

CONFORMITÉ

       IETF RFC 2396, HTML 4.0.

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  (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
       suffisament 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
       (ex : texte ou graphique, environnement graphique, localisation, outils
       disponibles) et invoque le bon outil quelque soit l’URI.

AUTEUR

       David A. Wheeler (dwheeler@dwheeler.com) a écrit cette page de  manuel.

VOIR AUSSI

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

TRADUCTION

       Christophe Blaess, 2003.