Passa al contenuto principale

4. Conformità agli URI

4.1. Uso negli slot di protocollo URI​

Poiché un URN è, sintatticamente, un URI nell'ambito dello schema "urn", in teoria un URN può essere collocato in qualsiasi slot di protocollo che ammetta un URI (per citarne solo alcuni, gli attributi "href" e "src" in HTML, l'elemento base in HTML, l'attributo "xml:base" in XML [XML-BASE] e l'attributo "xmlns" in XML per i nomi di namespace XML [XML-NAMES]).

Tuttavia, ciò non implica che, semanticamente, abbia sempre senso in pratica collocare un URN in un dato slot di protocollo URI; in particolare, poiché un URN potrebbe non specificare la posizione di una risorsa o nemmeno puntare indirettamente a una, potrebbe non essere appropriato collocare un URN in uno slot di protocollo URI che punta a una risorsa (ad esempio, i summenzionati attributi "href" e "src").

In definitiva, le linee guida su quando sia appropriato usare URI nell'ambito dello schema "urn" (o di qualsiasi altro schema) sono responsabilità delle specifiche dei singoli slot di protocollo URI (ad esempio, la specifica per l'attributo "xml:base" in XML potrebbe raccomandare che sia inappropriato usare URN in quello slot di protocollo). Questa specifica non può in alcun modo prevedere tutti i casi rilevanti, e non è compito di questa specifica imporre o limitare l'uso per singoli slot di protocollo.

4.2. Analisi sintattica​

In parte a causa della separazione della semantica degli URN dalla sintassi più generale degli URI, i processori generici di URI devono prestare particolare attenzione alle regole di analisi e di studio della RFC 3986 e, in particolare, devono trattare l'URI come opaco a meno che lo schema e i suoi requisiti non siano riconosciuti. In quest'ultimo caso, tali processori possono essere in grado di invocare un'elaborazione appropriata allo schema, ad esempio tramite un resolver di URN. Un resolver di URN può essere sia un resolver esterno di cui il resolver di URI è a conoscenza sia una funzionalità integrata nel resolver di URI. Si noti che questo requisito potrebbe imporre vincoli ai contesti in cui gli URN sono usati in modo appropriato; vedere la Sezione 4.1.

4.3. URN e riferimenti relativi​

La Sezione 5.2 della [RFC3986] descrive un algoritmo per convertire un riferimento URI che potrebbe essere relativo a un dato URI di base in "parsed components" del target di quel riferimento, che possono poi essere ricomposte secondo la Sezione 5.3 della RFC 3986 in un URI target. Questo algoritmo è problematico per gli URN perché la loro sintassi non supporta le necessarie componenti di percorso. Tuttavia, se l'algoritmo viene applicato indipendentemente da un particolare schema, dovrebbe funzionare in modo prevedibile anche per gli URN, con le seguenti precisazioni (la terminologia delle produzioni sintattiche è tratta dalla RFC 3986):

  1. Un sistema che incontra un <URI-reference> che obbedisce alla sintassi di <relative-ref>, indipendentemente dal fatto che abbia esplicitamente lo schema "urn" o meno, lo convertirà in un URI target come specificato nella RFC 3986.

  2. A causa delle aspettative di persistenza e stabilità degli URN, gli autori di documenti, ecc., che utilizzano URN dovrebbero in genere evitare l'uso dello schema "urn" in qualsiasi <URI-reference> che non sia strettamente un <URI> come specificato nella RFC 3986, compresi in particolare quelli che richiederebbero l'elaborazione di <relative-ref>.

4.4. Trasporto e visualizzazione​

Quando gli URN sono trasportati e scambiati, DEVONO (MUST) essere rappresentati nel formato qui definito. Inoltre, le applicazioni consapevoli degli URN sono fortemente incoraggiate a offrire l'opzione di visualizzare gli URN in questa forma canonica per consentirne la trascrizione diretta (ad esempio con tecniche di copia e incolla). Tali applicazioni potrebbero supportare la visualizzazione degli URN in una forma più amichevole per l'utente e potrebbero usare un set di caratteri che include caratteri non consentiti nella sintassi degli URN come definita in questa specifica (ad esempio, quando mostrano gli URN agli utenti, tali applicazioni potrebbero sostituire le stringhe codificate in percentuale con caratteri di un repertorio esteso come Unicode [UNICODE]).

Per ridurre al minimo la confusione dell'utente, qualsiasi applicazione che visualizza URI DOVREBBE (SHOULD) visualizzare l'URI completo (inclusi, per gli URN, lo schema "urn" e le eventuali componenti) per assicurare che non vi sia confusione tra i NID degli URN e gli identificatori degli schemi URI. Ad esempio, un URI che inizia con "urn:xmpp:" [RFC4854] è molto diverso da un URI che inizia con "xmpp:" [RFC5122]. Analogamente, un potenziale schema URI Digital Object Identifier (DOI) [DOI-URI] è diverso da, e possibilmente del tutto estraneo a, un possibile namespace URN DOI.

4.5. Progettazione e titolarità degli URI​

Come accennato, l'assegnazione degli URN all'interno di un namespace URN è un processo gestito, così come lo è l'assegnazione dei namespace URN stessi. Sebbene la progettazione degli URN da assegnare all'interno di un dato namespace URN sia ceduta da questa specifica al gestore del namespace URN, farlo in modo gestito evita i problemi inerenti alla generazione non gestita di URI, come descritto nelle raccomandazioni riguardanti la progettazione e la titolarità degli URI [RFC7320].