Provided by:
manpages-fr_3.32d0.2p4-1_all 
NOM
uri, url, urn - Identificateur de ressource uniforme (URI), comprenant
URL ou URN
SYNOPSIS
URI = [ URI_absolu | URI_relatif ] [ "#" fragment ]
URI_absolu = mecanisme ":" ( partie_hierarchique | partie_opaque )
URI_relatif = ( chemin_reseau | chemin_absolu | chemin_relatif ) [ "?" requete
mecanisme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
"file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...
partie_hierarchique = ( chemin_reseau | chemin_absolu ) [ "?" requete ]
chemin_reseau = "//" autorite [ chemin_absolu ]
chemin_absolu = "/" segments_chemin
chemin_relatif = segment_relatif [ chemin_relatif ]
DESCRIPTION
Un Identificateur de Ressource Uniforme (URI) est une courte chaine de
caracteres identifiant une ressource physique ou abstraite (par exemple
une page web). Une Localisation de Ressource Uniforme (URL) est un URI
qui identifie une ressource a travers son moyen d'acces (sa
<< position >> reseau par exemple), plutot 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 meme si la ressource
cesse d'exister ou devient indisponible.
Les URI constituent le mecanisme standard pour nommer les destinations
des liens hypertextes pour les outils comme les navigateurs web. La
chaine << 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 etre absolus ou relatifs. Un identificateur absolu
reference une ressource independamment du contexte, alors qu'un
identificateur relatif reference une ressource en decrivant la
difference par rapport au contexte courant. Dans les references de
chemins relatifs, les segments complets << . >> et << .. >> ont des
significations particulieres : << le niveau actuel dans la
hierarchie >> et << le niveau au-dessus dans la hierarchie >>,
respectivement, tout comme dans les systemes type UNIX. Un segment de
chemin qui contient un caractere deux-points ne peut pas etre utilise
comme premier segment du chemin d'un URI (par exemple << ceci:cela >>),
car on le confondrait avec le mecanisme. Precedez 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 peripherique par
une barre verticale dans les URI, ainsi << C: >> devient << C| >>.
Un identificateur de fragment, s'il est present, reference une portion
particuliere de la ressource ; le texte apres le << # >> identifie le
fragment. Un URI commencant par << # >> reference le fragment dans la
ressource courante.
Utilisation
Il y a plusieurs schemas d'URI differents, chacun ajoutant des regles
et des significations specifiques, mais ils sont volontairement rendus
le plus ressemblants possible. Par exemple, plusieurs schemas d'URL
permettent le format suivant pour decrire l'autorite d'un chemin
reseau, que l'on appellera serveur_ip (les crochets encadrent les
parties optionnelles) :
serveur_ip = [user [ : password ] @ ] h^ote [ : port]
Ce format permet d'inserer eventuellement un nom d'utilisateur, suivi
eventuellement d'un mot de passe, et/ou un numero de port. La partie
h^ote est le nom de l'ordinateur, soit son nom determine par le DNS,
soit son adresse IP (numeros separes 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'identite fred (et le mot de passe
fredpassword) en utilisant le port 8080. Evitez d'utiliser les mots de
passe dans les URI a cause des risques lies a la securite sitot que
l'on ecrit un mot de passe. Si l'URL indique un nom d'utilisateur et
pas de mot de passe, et si le serveur distant reclame un mot de passe,
alors le programme interpretant l'URL peut en demander un a
l'utilisateur.
Voici les mecanismes les plus courants utilises sur les systemes type
UNIX, compris par de nombreux outils. Notez que beaucoup d'outils
gerant les URI ont aussi des mecanismes internes ou specialises ;
consultez la documentation de ces outils pour plus de details.
http - Serveur Web (HTTP)
http://serveur_ip/chemin
http://serveur_ip/chemin?requ^ete
Il s'agit d'une URL accedant a un serveur web (HTTP). Le port par
defaut est 80. Si le chemin reference un repertoire, le serveur
choisira ce qu'il renverra. Habituellement, si un fichier nomme
<< index.html >> ou << index.htm >> est present, son contenu est
renvoye. Sinon, il cree et renvoie une liste des fichiers dans le
repertoire en cours avec les liens appropries. Un exemple :
<http://lwn.net>.
Une requete peut etre formulee dans le format archaique << isindex >>,
consistant en mot ou phrase sans signe egal << = >>. Une requete peut
aussi etre dans le format << GET >> plus long, qui a une ou plusieurs
entrees de requetes de la forme cl'e=valeur separees par un caractere
<< et commercial >> << & >>. Notez que la cl'e peut etre repetee
plusieurs fois, et c'est au serveur web et ses programmes applicatifs
de determiner s'il y a une signification pour cela. Il y a une
interaction malheureuse avec HTML/XML/SGML et le format de requete GET.
Quand une telle requete avec plusieurs cles est incluse dans un
document SGML/XML (y compris HTML), le << et commercial >> << & >> doit
etre reecrit sous forme << & >>. Notez que toutes les requetes
n'utilisent pas ce format ; elles peuvent etre trop longues pour etre
stockee en URL et utilisent un mecanisme d'interaction different
(appele POST) sans inclure les donnees dans l'URI. Consultez la
specification Common Gateway Interface (CGI) a l'adresse
<http://www.w3.org/CGI> pour plus de details.
ftp - File Transfer Protocol (FTP)
ftp://serveur_ip/chemin
Cette URL accede a un fichier a travers le protocole FTP. Le port par
defaut (pour les commandes) est 21. Si aucun nom d'utilisateur n'est
inclus, l'utilisateur << anonymous >> est employe, et dans ce cas de
nombreux clients fournissent l'adresse courriel du requerant 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 s'electeur
gopher://serveur_ip/type_gopher s'electeur%09recherche
gopher://serveur_ip/type_gopher s'electeur%09recherche%09chaine_gopher+
Le port gopher par defaut est 70. Le type_gopher est un champ compose
d'un unique caractere indiquant le type de ressource Gopher a laquelle
l'URL fait reference. Le chemin entier paut aussi etre vide, auquel cas
le delimiteur << / >> est aussi optionnel et le type_gopher prend la
valeur par defaut << 1 >>.
selecteur est une chaine de selecteur Gopher. Dans le protocole Gopher,
la chaine de selecteur est une sequence d'octets pouvant contenir tous
les octets sauf 09 hexadecimal (HT ACSII ou Tabulation), 0A hexadecimal
(LF ACSII), et 0D (CR ACSII).
mailto - Adresse courriel
mailto:adresse-courriel
Il s'agit d'une adresse courriel, en principe de la forme nom@nom_h^ote.
Consultez mailaddr(7) pour plus d'informations sur le format correct
d'une adresse courriel. Notez que les caracteres % doivent etre
transformes 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 hierarchique delimite par des points,
comme << comp.infosystems.www.misc >>. Si nom-groupe-news est << * >>
(comme dans <news:*>), l'URL reference tous les groupes news
disponibles. Un exemple : <news:comp.lang.ada>.
Un id-message correspond au champ identificant Message-ID de IETF
RFC 1036, <http://www.ietf.org/rfc/rfc1036.txt> sans les chevrons
<< < >> et << > >> ; il prend la forme unique@nom-domaine-complet. Un
identificateur de message peut etre distingue d'un nom de groupe de
news par la presence du caractere << @ >>.
telnet - Connexion telnet
telnet://serveur_ip/
Le mecanisme d'URL Telnet est utilise pour afficher un service
interactif accessible par le protocole Telnet. Le caractere << / >>
final peut etre omis. Le port par defaut est 23. Un exemple :
<telnet://melvyl.ucop.edu/>.
file - Fichier normal
file://serveur_ip/segments_chemins
file:segments_chemins
Ceci represente un fichier ou un repertoire accessible localement. En
particulier, h^ote peut etre la chaine << localhost >> ou une chaine
vide ; elle est interpretee comme << la machine sur laquelle l'URL est
en cours d'interpretation >>. Si le chemin conduit a un repertoire, le
navigateur devrait afficher le contenu du repertoire avec des liens
pour chaque element. Tous les navigateurs ne le font pas encore. KDE
prend en charge les fichiers generes par l'URL <file:/cgi-bin>. Si le
fichier n'est pas trouve, l'analyseur du navigateur peut essayer de
developper le nom du fichier (consultez glob(7) et glob(3)).
Le second format (par ex. <file:/etc/passwd>) est le format correct
pour referencer 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 chaine vide en guise
de nom de serveur <file:///etc/passwd> ; cette forme a le meme effet et
est reconnue facilement comme un URI par les analyseurs des anciens
programmes. Notez que si vous desirez vraiment ecrire << debuter de
l'emplacement actuel >>, n'indiquez pas de mecanisme ; utilisez une
adresse relative comme <../test.txt>, qui est independante du
mecanisme. Un exemple de ce mecanisme est <file:///etc/passwd>.
man - Pages de manuel
man:nom-commande
man:nom-commande(section)
Ceci reference les pages de documentation en ligne (man) locales. Le
nom de la commande peut etre suivi eventuellement de parentheses et
d'un numero de section. Consultez man(7) pour plus de renseignements
sur la signification du numero de section. Ce mecanisme d'URI est
unique aux systemes UNIX (comme Linux) et n'est pas encore enregistre
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 mecanisme reference les pages de documentation en-ligne info (creees
par les fichiers texinfo), un format utilise par les outils GNU. Ce
mecanisme est specifique aux systemes UNIX (comme Linux) et n'est pas
encore enregistre 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 remplaces par des soulignes. Les deux formats suivants
sont ceux de Kde ; les espaces doivent rester tels quels, meme si c'est
interdit dans les standards d'URI. On peut esperer que dans l'avenir la
plupart des outils comprendront les deux formats et accepteront des
soulignes en remplacement des espaces. Dans tous les cas, le format
sans nom de noeud est suppose 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:cha^ine
Ce mecanisme parcourt une base de donnees de courtes (une ligne)
descriptions des commandes et renvoie une liste des descriptions
contenant la chaine. Seules les correspondances de mots complets sont
renvoyees. Consultez whatis(1). Ce mecanisme est unique aux systemes
UNIX (comme Linux) et n'est pas encore enregistre par l'IETF.
ghelp - Documentation d'aide Gnome
ghelp:nom-application
Ceci charge la documentation d'aide Gnome pour l'application indiquee.
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?port'ee
ldap://hostport/dn?attributs?port'ee?filtre
ldap://hostport/dn?attributs?port'ee?filtre?extensions
Ce mecanisme prend en charge les requetes utilisant le protocole
Lightweight Directory Access Protocol (LDAP), pour interroger un
ensemble de serveurs a propos d'informations organisees
hierarchiquement (comme des gens ou des ressources de calcul). Des
informations supplementaires sur les mecanismes d'URL LDAP sont
disponibles dans la RFC 2255 : <http://www.ietf.org/rfc/rfc2255.txt>
Les composants de l'URL sont :
hostport le serveur LDAP a interroger, ecrit comme un nom d'hote
suivi eventuellement par un deux-points et un numero de
port. Le port TCP pour le LDAP est 389. Si le nom est vide,
le client determine le serveur LDAP a utiliser.
dn Le nom complet (Distinguished Name) LDAP, qui identifie
l'objet de base de la recherche LDAP (voir RFC 2253
<http://www.ietf.org/rfc/rfc2253.txt> section 3).
attributs une liste d'attributs a renvoyer separes par des virgules ;
voir la RFC 2251 section 4.1.5. Par defaut tous les
attributs sont renvoyes..
portee indique la portee de la recherche qui peut etre << base >>
(recherche d'objet de base), << one >> (recherche sur un
niveau), ou << sub >> (recherche dans un sous-arbre). Par
defaut, on considere << base >>.
filtre indique le filtre de recherche (sous-ensemble des entrees a
renvoyer). Par defaut, toutes les entrees sont renvoyees.
Consultez RFC 2254 <http://www.ietf.org/rfc/rfc2254.txt>
section 4.
extensions une liste de paires type=valeur separees par des virgules,
ou la portion =valeur peut etre omise pour les options ne
la necessitant pas. Une extension prefixee par un << ! >>
est critique (doit etre pris en charge pour etre valide),
sinon elle est non-critique (facultative).
Les requetes LDAP sont plus faciles a comprendre par l'exemple. Voici
une requete demandant a ldap.itd.umich.edu des informations a propos de
l'Universite 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 a host.com, sur le port 6666 des informations sur la
personne de nom courant (cn) << Babs Jensen >> a 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 mecanisme designe une base de donnees WAIS, une recherche ou un
document (voir IETF RFC 1625 <http://www.ietf.org/rfc/rfc1625.txt> pour
plus de renseignements sur WAIS). Hostport est le nom d'hote, suivi
eventuellement d'un deux-points et d'un numero de port (par defaut
210).
La premiere forme designe une base de donnees WAIS pour les recherches.
La seconde designe une recherche particuliere dans la base WAIS
indiquee. La troisieme forme designe un document particulier a
retrouver dans la base de donnees WAIS. wtype est la designation WAIS
du type d'objet et wpath est l'identificateur WAIS du document.
Autres m'ecanismes
Il existe d'autres mecanismes URI. La plupart des outils traitant les
URI acceptent un jeu d'URI internes (par exemple, Mozilla a un
mecanisme about: pour les informations internes, et le navigateur
d'aide Gnome a un mecanisme toc: pour diverses operations). Il y a de
nombreux mecanismes qui ont ete definis mais pas tres utilises pour
l'instant (par exemple, prospero). Le mecanisme nntp: est deconseille
en faveur de celui news:. Les URN seront prises en charge par le
mecanisme urn: avec des espaces de noms hierarchique (p.ex. :
urn:ietf:... pour les documents IETF). Pour le moment, les URN ne sont
pas tres largement implementes. Tous les outils ne gerent pas tous les
mecanismes.
Codage des caract`eres
Les URI utilisent un nombre limite de caracteres afin d'etre saisis et
utilises dans de nombreuses situations.
Les caracteres suivants sont reserves ; ils peuvent apparaitre dans un
URI, mais leurs usages est limites aux fonctionnalites reservees (les
donnees conflictuelles doivent etre protegees avant de former l'URI) :
; / ? : @ & = + $ ,
Les caracteres non-reserves peuvent etre inclus dans un URI. Les
caracteres non-reserves incluent les majuscules et minuscules
anglaises, les chiffres decimaux, et l'ensemble suivant de signes de
ponctuation et de symboles :
- _ . ! ~ * ' ( )
Tous les autres caracteres doivent etre proteges. Un octet protege est
encode sous forme d'un triplet de caracteres, consistant en un signe
pourcent << % >> suivi de deux chiffres hexadecimaux representant le
code de l'octet (les lettres hexadecimales peuvent etre en majuscules
ou en minuscules). Par exemple un espace blanc doit etre protege sous
forme << %20 >>, une tabulation << %09 >> et le << & >> en << %26 >>.
Comme le caractere "% >>" a toujours un role reserve pour proteger les
autres caracteres, il faut le proteger sous forme << %25 >>. Il est
courant de proteger le caractere espace en symbole plus << + >> dans
les requetes. Cette pratique n'est pas defini uniformement dans les RFC
correspondantes (qui recommandent %20 plutot) mais tous les outils
acceptant les URI avec des requetes preparees ainsi. Une URI est
toujours montree dans sa forme protegee.
Les caracteres non-reserves peuvent etre proteges sans modifier la
semantique de l'URI, mais il faut l'eviter sauf si l'URI est utilise
dans un contexte qui ne permet pas l'utilisation du caractere non
protege. Par exemple << %7E >> est parfois utilise a la place de
<< ~ >> dans les URL HTTP mais les deux sont en realite equivalents
dans ce contexte.
Pour les URI qui doivent manipuler des caracteres hors du jeu ASCII, la
specification HTML 4.01 (section B.2) et la RFC 2718 (section 2.2.5)
preconisent l'approche suivante :
1. traduire le caractere en sequence UTF-8 (RFC 2279) -- consultez
utf-8(7) -- puis
2. utiliser le mecanisme d'echappement d'URI, c'est-a-dire, utiliser
les %HH pour coder les octets non-surs.
'Ecrire un URI
Lorsqu'il est ecrit, un URI doit etre place entre guillemets
("http://www.kernelnotes.org"), encadre par des chevrons
(<http://lwn.net>), ou place sur une ligne independante. Un
avertissement a propos des guillemets : Ne jamais introduire une
ponctuation supplementaire (comme le point final d'une phrase ou la
virgule separant les elements d'une liste) a l'interieur de l'URI, car
cela modifierait sa valeur (N.d.T. : cet avertissement vaut surtout
pour les anglo-saxons ; en francais l'usage veut que les elements de
ponctuations restent a l'exterieur des guillemets). On peut utiliser
les chevrons a la place, ou basculer sur un systeme de notation qui
n'incopore aucun caractere supplementaire a l'interieur des marques de
citation. Ce systeme (N.d.T. : le notre !), appele << nouveau >> ou
<< logique >> par les << Hart's Rules >> et le << Oxford Dictionnary
for Writes and Editors >>, est la pratique preferee des hackers dans le
monde entier. Consultez la section sur le style d'ecriture dans le
Jargon File
(http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html pour plus
de details. Les documentations anciennes suggerent d'inserer le prefixe
<< URL: >> juste avant un URI, mais cette forme n'a jamais ete utilisee
reellement.
La syntaxe des URI a ete concue pour eviter les ambiguites. Toutefois,
comme les URI sont devenus de plus en plus repandus, les medias
traditionnels television, radio, journaux et magazines...) ont utilise
de maniere croissante des abreviations d'URI, consistant en la seule
partie autorite et segments de chemin de la ressource (par exemple
<www.w3.org/Addressing>). De tels references sont surtout prevues pour
une interpretation humaine, avec la supposition que la comprehension du
contexte permet de completer l'URI (par exemple les noms d'hotes
commencant par << www >> se prefixent avec << http:// >> et les noms
commencant par << ftp >> doivent se prefixer avec << ftp:// >>). De
nombreux clients resolvent ces references avec de telles heuristiques.
Elle peuvent toutefois evoluer, particulierement quand de nouveaux
mecanismes sont introduits. Comme les URI abreges ont la meme syntaxe
qu'un chemin d'URL relative, les references abregees ne sont pas
utilisables lorsque des URI relatifs sont autorises. N'utilisez pas
d'URI abreges comme liens hypertexte dans un document ; utilisez le
format standard decrit ici.
CONFORMIT'E
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
systeme Linux devrait etre capable de traiter (directement ou
indirectement) tous les mecanismes decrits ici, y compris man: et
info:. Sous-traiter ces elements a un autre programme est tout a fait
acceptable, et meme encourage.
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 donnees, 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 recemment ajoutee, ou
incluent juste l'URI dans le texte (les visualiseurs doivent detecter
le :// comme portion d'URI).
Les environnements Gnome et Kde divergent actuellement sur les URI
qu'ils acceptent, en particulier dans leurs systemes 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 prefere
l'approche Kde, bien qu'un format plus regulier serait encore
meilleur). En general, Kde utilise <file:/cgi-bin/> comme prefixe pour
les fichiers generes. Kde prefere la documentation en Html, accessible
avec <file:/cgi-bin/helpindex>. Gnome prefere le mecanisme ghelp pour
stocker et retrouver la documentation. Aucun navigateur ne gere les
references file: vers un repertoire a l'heure ou j'ecris ces lignes, ce
qui rend difficile de se referer a un repertoire avec un URI navigable.
Comme indique plus haut, ces environnements different sur la gestion du
mecanisme info:, probablement leur plus importante divergence. On
espere que Gnome et Kde vont converger vers des formats d'URI communs,
et la future version de cette page decrira le resultat de cette
convergence.
S'ecurit'e
Un URI ne pose pas de probleme de securite par lui-meme. Il n'y a
aucune garantie qu'une URL, qui localise une ressource a un moment
donne continuera de le faire. Pas plus qu'il n'y a de garantie qu'une
URL ne localisera pas une ressource differente a un autre moment. Les
seules garanties peuvent etre fournies par les personnes qui gerent
l'espace de noms de la ressource en question.
Il est parfois possible de construire une URL de maniere qu'une
tentative de realiser une operation apparemment benigne, comme acceder
a la ressource associee, va en realite produire une action
eventuellement dommageable pour le correspondant. Les URL non sures
sont typiquement construites en indiquant un numero de port differents
de ceux reserves pour les protocoles en question. Le client, croyant
contacter un site, va en realite engager un autre protocole. Le contenu
de l'URL contient des instructions, qui interpretees par l'autre
protocole, produisent des resultats inattendus. Un exemple a ete
l'emploi d'une URL Gopher pour envoyer un message falsifie et indesire
sur un serveur SMTP.
Il faut etre prudent en utilisant une URL qui indique un numero de port
different de celui du protocole, particulierement si ce numero est dans
l'espace reserve.
Il faut s'assurer que lorsque l'URI contient des delimiteurs proteges
pour un protocole donne (par exemple CR et LF pour le protocole telnet)
qu'ils ne soient pas << deproteges >> avant la transmission. Ceci peut
violer le protocole, mais evite le risque que ces caracteres servent a
simuler une operation dans ce protocole, ce qui peut conduire a des
actions distantes eventuellement nocives.
Il est clairement deraisonnable d'utiliser un URI qui contient un mot
de passe cense etre secret. En particulier, l'utilisation du mot de
passe dans la partie << info utilisateur >> de l'URI est fortement
deconseille, sauf s'il s'agit d'un de ces cas rares ou 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 mecanisme d'URI pour la documentation
generale en-ligne, dans des formats arbitraires. Les reference de la
forme <file:///usr/doc/ZZZ> ne fonctionnent pas, car differentes
distributions et installations locales peuvent placer les fichiers dans
divers repertoires (cela peut etre /usr/doc, ou /usr/local/doc, ou
/usr/share, ou autre part). De meme, le repertoire ZZZ change en
principe avec le numero de version (bien que le developpement des noms
de fichiers puisse partiellement couvrir ce probleme). Finalement,
l'utilisation du mecanisme file: n'est pas recommandee pour les gens
qui consultent la documentation dynamiquement depuis Internet plutot
que de la telecharger sur leur systeme de fichiers local. Un mecanisme
d'URI sera peut etre ajoute dans l'avenir (p.ex. : << userdoc: >>) pour
permettre aux programme d'inclure des references vers de la
documentation plus detaillees sans avoir a connaitre l'emplacement
exact de celle-ci. Autrement, une version future des specifications du
systeme de fichiers peut decrire les emplacements de maniere
suffisamment precise pour que le mecanisme file: soit capable de situer
la documentation.
De nombreux programmes et formats de fichiers n'incluent aucune maniere
d'incorporer ou l'implementer des liens utilisant les URI.
Beaucoup de programmes ne traitent pas tous les formats URI
differents ; il devrait y avoir un mecanisme standard pour charger un
URI quelconque qui detecte automatiquement l'environnement utilisateur
(p.ex. : texte ou graphique, environnement de bureau, preferences de
l'utilisateur, outils en cours d'execution) et invoque le bon outil
quelque soit l'URI.
VOIR AUSSI
lynx(1), man2html(1), mailaddr(7), utf-8(7), IETF RFC 2255
<http://www.ietf.org/rfc/rfc2255.txt>
COLOPHON
Cette page fait partie de la publication 3.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.