Provided by: manpages-fr_2.80.1-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 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
       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 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  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 à renvoyer séparés par des virgules ;
                   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 (p.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 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 2.80 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> ».