1. Introduzione (Introduction)

Gli URI [RFC3986] includono molto spesso dati di applicazione strutturati. Ciò può includere artefatti da filesystem (che spesso appaiono nel componente percorso) e informazioni utente (spesso nel componente query). In alcuni casi, possono esserci anche dati specifici dell'applicazione nel componente autorità (ad esempio, alcune applicazioni sono distribuite su più hostname per consentire una forma di partizionamento o distribuzione).

Le implementazioni possono imporre ulteriori vincoli sulla struttura degli URI; ad esempio, molti server web utilizzano l'estensione del file dell'ultimo segmento del percorso per determinare il tipo di media della risposta. Allo stesso modo, le applicazioni preconfezionate hanno spesso URI altamente strutturati che possono essere modificati solo in modi limitati (spesso, solo l'hostname e la porta su cui sono distribuiti).

Poiché il proprietario dell'URI (come definito in [webarch], sezione 2.2.2.1) sta scegliendo di utilizzare il server o l'applicazione, questo può essere visto come una delega ragionevole di autorità. Tuttavia, quando tali convenzioni sono imposte da una parte diversa dal proprietario, ciò può avere diversi effetti potenzialmente dannosi:

• Collisioni - Man mano che più convenzioni ad hoc per la struttura URI vengono standardizzate, diventa più probabile che ci siano collisioni tra di esse (specialmente considerando che server, applicazioni e singole distribuzioni avranno le proprie convenzioni).

• Diluizione - Quando le informazioni aggiunte a un URI sono effimere, ciò diluisce la sua utilità riducendone la stabilità (vedi [webarch], sezione 3.5.1) e può causare l'esistenza di diverse forme alternative dell'URI (vedi [webarch], sezione 2.3.1).

• Rigidità - La sintassi URI fissa spesso interferisce con i modelli di distribuzione desiderati. Ad esempio, se un'autorità desidera offrire diverse applicazioni su un singolo hostname, diventa difficile o impossibile farlo se i loro URI non consentono la flessibilità richiesta.

• Difficoltà operative (Operational Difficulty) - Supportare alcune convenzioni URI può essere difficile in alcune implementazioni. Ad esempio, specificare che un particolare parametro di query deve essere utilizzato con URI "http" può precludere l'uso di server web che servono la risposta da un filesystem. Allo stesso modo, un'applicazione che fissa un percorso base per il suo funzionamento (ad es. "/v1") rende impossibile distribuire altre applicazioni con lo stesso prefisso sullo stesso host.

• Assunzioni del client (Client Assumptions) - Quando le convenzioni vengono standardizzate, alcuni client presumeranno inevitabilmente che gli standard siano in uso quando si vedono tali convenzioni. Ciò può portare a problemi di interoperabilità; ad esempio, se una specifica documenta che il parametro di query URI "sig" indica che il suo payload è una firma crittografica per l'URI, può portare a comportamenti indesiderati.

Pertanto, la pubblicazione di uno standard che vincola una struttura URI esistente in modi che non sono esplicitamente consentiti dall'[RFC3986] (di solito, aggiornando la definizione dello schema URI) è a volte problematica, sia per questi motivi sia perché la struttura di un URI deve essere saldamente sotto il controllo del suo proprietario.

Questo documento spiega alcune migliori pratiche attuali per stabilire strutture, convenzioni e formati URI negli standard. Offre anche strategie per le specifiche nella sezione 3.

1.1. Pubblico destinato (Intended Audience)

Le linee guida e i requisiti di questo documento si rivolgono agli autori di specifiche che vincolano la sintassi o la struttura degli URI o delle loro parti. Due classi di tali specifiche sono specificamente indicate:

• Estensioni di protocollo ("Extensions") - Specifiche che offrono nuove capacità che potrebbero applicarsi a qualsiasi identificatore o a un ampio sottoinsieme di identificatori possibili, ad esempio, un nuovo meccanismo di firma per URI "http", metadati per qualsiasi URI o un nuovo formato.

• Applicazioni che utilizzano URI ("Applications") - Specifiche che utilizzano URI per soddisfare esigenze specifiche, ad esempio, un'interfaccia HTTP a informazioni particolari su un host.

I requisiti che si rivolgono alla classe generica "Specifiche" si applicano a tutte le specifiche, incluse quelle enumerate sopra e altre.

Si noti che questa specifica non dovrebbe (SHOULD NOT) essere interpretata come impedimento all'allocazione del controllo degli URI da parte di parti che li possiedono legittimamente o hanno delegato tale proprietà; ad esempio, una specifica potrebbe legittimamente definire la semantica di un URI sul sito web IANA come parte dell'istituzione di un registro.

Potrebbero esistere specifiche IETF esistenti che già deviano dalle linee guida in questo documento. In questi casi, spetta alle comunità pertinenti (cioè, quelle dello schema URI nonché qualsiasi comunità pertinente che ha prodotto la specifica in questione) determinare un risultato appropriato, ad esempio, aggiornare la definizione dello schema o modificare la specifica.

1.2. Convenzioni notazionali (Notational Conventions)

Le parole chiave "MUST" (deve), "MUST NOT" (non deve), "REQUIRED" (richiesto), "SHALL" (deve), "SHALL NOT" (non deve), "SHOULD" (dovrebbe), "SHOULD NOT" (non dovrebbe), "RECOMMENDED" (raccomandato), "NOT RECOMMENDED" (non raccomandato), "MAY" (può) e "OPTIONAL" (opzionale) in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.