1. Introduction

Les URI [RFC3986] incluent très souvent des données d'application structurées. Cela peut inclure des artefacts de systèmes de fichiers (apparaissant souvent dans le composant chemin) et des informations utilisateur (souvent dans le composant requête). Dans certains cas, il peut même y avoir des données spécifiques à l'application dans le composant autorité (par exemple, certaines applications sont réparties sur plusieurs noms d'hôte pour permettre une forme de partitionnement ou de répartition).

Les implémentations peuvent imposer des contraintes supplémentaires sur la structure des URI ; par exemple, de nombreux serveurs Web utilisent l'extension de fichier du dernier segment de chemin pour déterminer le type de média de la réponse. De même, les applications préemballées ont souvent des URI hautement structurés qui ne peuvent être modifiés que de manière limitée (souvent, seulement le nom d'hôte et le port sur lesquels ils sont déployés).

Parce que le propriétaire de l'URI (tel que défini dans [webarch], section 2.2.2.1) choisit d'utiliser le serveur ou l'application, cela peut être considéré comme une délégation raisonnable d'autorité. Cependant, lorsque de telles conventions sont imposées par une partie autre que le propriétaire, cela peut avoir plusieurs effets potentiellement préjudiciables :

• Collisions - À mesure que de plus en plus de conventions ad hoc pour la structure URI sont standardisées, il devient plus probable qu'il y ait des collisions entre elles (en particulier compte tenu du fait que les serveurs, les applications et les déploiements individuels auront leurs propres conventions).

• Dilution - Lorsque les informations ajoutées à un URI sont éphémères, cela dilue son utilité en réduisant sa stabilité (voir [webarch], section 3.5.1) et peut entraîner l'existence de plusieurs formes alternatives de l'URI (voir [webarch], section 2.3.1).

• Rigidité - La syntaxe URI fixe interfère souvent avec les modèles de déploiement souhaités. Par exemple, si une autorité souhaite offrir plusieurs applications sur un seul nom d'hôte, il devient difficile voire impossible de le faire si leurs URI ne permettent pas la flexibilité requise.

• Difficulté opérationnelle (Operational Difficulty) - Le support de certaines conventions URI peut être difficile dans certaines implémentations. Par exemple, spécifier qu'un paramètre de requête particulier doit être utilisé avec les URI "http" peut empêcher l'utilisation de serveurs Web qui servent la réponse depuis un système de fichiers. De même, une application qui fixe un chemin de base pour son fonctionnement (par exemple, "/v1") rend impossible le déploiement d'autres applications avec le même préfixe sur le même hôte.

• Hypothèses des clients (Client Assumptions) - Lorsque les conventions sont standardisées, certains clients supposeront inévitablement que les normes sont utilisées lorsque ces conventions sont observées. Cela peut entraîner des problèmes d'interopérabilité ; par exemple, si une spécification documente que le paramètre de requête URI "sig" indique que sa charge utile est une signature cryptographique pour l'URI, cela peut entraîner un comportement indésirable.

Par conséquent, la publication d'une norme qui contraint une structure URI existante de manières qui ne sont pas explicitement autorisées par [RFC3986] (généralement, en mettant à jour la définition du schéma URI) est parfois problématique, à la fois pour ces raisons et parce que la structure d'un URI doit être fermement sous le contrôle de son propriétaire.

Ce document explique certaines meilleures pratiques actuelles pour établir des structures, conventions et formats URI dans les normes. Il propose également des stratégies pour les spécifications dans la section 3.

1.1. Public visé (Intended Audience)

Les directives et exigences de ce document ciblent les auteurs de spécifications qui contraignent la syntaxe ou la structure des URI ou de leurs parties. Deux classes de telles spécifications sont spécifiquement mentionnées :

• Extensions de protocole ("Extensions") - Spécifications qui offrent de nouvelles capacités qui pourraient s'appliquer à n'importe quel identifiant ou à un grand sous-ensemble d'identifiants possibles, par exemple, un nouveau mécanisme de signature pour les URI "http", des métadonnées pour tout URI ou un nouveau format.

• Applications utilisant des URI ("Applications") - Spécifications qui utilisent des URI pour répondre à des besoins spécifiques, par exemple, une interface HTTP vers des informations particulières sur un hôte.

Les exigences qui ciblent la classe générique "Spécifications" s'appliquent à toutes les spécifications, y compris celles énumérées ci-dessus et d'autres.

Notez que cette spécification ne doit pas (SHOULD NOT) être interprétée comme empêchant l'allocation du contrôle des URI par des parties qui les possèdent légitimement ou ont délégué cette propriété ; par exemple, une spécification peut légitimement définir la sémantique d'un URI sur le site Web de l'IANA dans le cadre de l'établissement d'un registre.

Il peut exister des spécifications IETF existantes qui s'écartent déjà des directives de ce document. Dans ces cas, il appartient aux communautés concernées (c'est-à-dire celles du schéma URI ainsi que toute communauté pertinente qui a produit la spécification en question) de déterminer un résultat approprié, par exemple, mettre à jour la définition du schéma ou modifier la spécification.

1.2. Conventions de notation (Notational Conventions)

Les mots-clés "MUST" (doit), "MUST NOT" (ne doit pas), "REQUIRED" (requis), "SHALL" (doit), "SHALL NOT" (ne doit pas), "SHOULD" (devrait), "SHOULD NOT" (ne devrait pas), "RECOMMENDED" (recommandé), "NOT RECOMMENDED" (non recommandé), "MAY" (peut) et "OPTIONAL" (optionnel) dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.