1. Introduzione

Un Uniform Resource Name (URN) è un Uniform Resource Identifier (URI) [RFC3986] che viene assegnato nell'ambito dello schema URI "urn" e di un particolare namespace URN, con l'intento che l'URN sia un identificatore di risorsa persistente e indipendente dalla posizione. Un namespace URN è una raccolta di tali URN, ciascuno dei quali è (1) univoco, (2) assegnato in modo coerente e gestito e (3) assegnato secondo una definizione comune. (Alcuni namespace URN creano nomi che esistono solo come URN, mentre altri assegnano URN basati su nomi già creati in sistemi di identificatori non URN, come gli ISBN [RFC3187], gli ISSN [RFC3044] o le RFC [RFC2648].)

L'assegnazione degli URN è effettuata da un'organizzazione (o, in alcuni casi, secondo un algoritmo o un altro processo automatizzato) a cui è stato formalmente delegato un namespace URN nell'ambito dello schema "urn" (ad esempio, un URN nel namespace URN "example" [RFC6963] potrebbe avere la forma "urn:example:foo").

Questo documento si basa su due presupposti chiave:

1. L'assegnazione di un URN è un processo gestito.

2. Lo spazio dei namespace URN è esso stesso gestito.

Mentre altri schemi URI possono consentire che gli identificatori di risorsa siano scelti e assegnati liberamente, non è questo il caso degli URN. La correttezza sintattica di un nome che inizia con "urn:" non è sufficiente a renderlo un URN. Affinché il nome sia un URN valido, l'identificatore di namespace (NID) deve essere registrato in conformità con le regole definite qui, e le parti rimanenti della porzione assigned-name dell'URN devono essere generate in conformità con le regole del namespace URN registrato.

Affinché le informazioni sia sulla sintassi degli URN sia sui namespace URN siano disponibili in un unico luogo, questo documento fa quanto segue:

1. Definisce la sintassi canonica per gli URN in generale (in modo coerente con la sintassi degli URI), specifica i metodi per determinare l'URN-equivalence e discute la conformità agli URI.

2. Specifica un metodo per definire un namespace URN e associarlo a un particolare NID, e descrive le procedure per registrare i NID degli URN presso l'Internet Assigned Numbers Authority (IANA).

Per quanto riguarda la sintassi degli URN e i namespace URN, questo documento modernizza e sostituisce le specifiche originali per la sintassi degli URN [RFC2141] e per la definizione e la registrazione dei namespace URN [RFC3406]. Queste modifiche si basano sui requisiti chiave forniti nella descrizione funzionale originale degli URN [RFC1737] e sulle lezioni di molti anni di esperienza. In quei documenti originali e nel presente documento, l'intento è definire gli URN in modo coerente affinché, ove possibile in pratica, l'analisi, la gestione e la risoluzione degli URN possano essere indipendenti dal namespace URN all'interno del quale un dato URN è assegnato.

Insieme al contributo di diverse comunità di utenti chiave, la storia e le esperienze con gli URN hanno imposto un ampliamento della definizione di URN per supportare nuove funzionalità, compreso l'uso di sintassi esplicitamente riservata alla standardizzazione futura nella RFC 2141. Tutti i namespace URN e gli URN che erano validi secondo le specifiche precedenti rimangono validi, anche se può essere utile aggiornare le definizioni di alcuni namespace URN per sfruttare le nuove funzionalità.

Le considerazioni che precedono, insieme alle varie differenze tra gli URN e gli URI che sono locator (nello specifico gli URL) nonché alla maggiore attenzione dedicata agli URL nella RFC 3986 in quanto successore finale di [RFC1738] e [RFC1808], possono portare ad alcune interpretazioni della RFC 3986 e di questa specifica che appaiono (o forse sono effettivamente) non del tutto coerenti, specialmente per quanto riguarda azioni o semantiche diverse dalla sintassi di base stessa. Se si presentano tali situazioni, le discussioni sugli URN e sui namespace URN dovrebbero essere interpretate secondo questo documento e non per estrapolazione dalla RFC 3986.

I riepiloghi delle modifiche rispetto alle RFC 2141 e 3406 compaiono rispettivamente nelle Appendici B e C. Questo documento rende obsolete sia la [RFC2141] sia la [RFC3406]. Pur non aggiornando né sostituendo esplicitamente la [RFC1737] o la [RFC2276], il lettore che fa riferimento a quei documenti dovrebbe essere consapevole che il modello concettuale degli URN in questo documento è leggermente diverso da quello di quelle specifiche più vecchie.

1.1. Terminologia

I seguenti termini si distinguono tra loro come descritto di seguito:

URN: un URI (come definito nella RFC 3986) che utilizza lo schema "urn" e che possiede le proprietà di un "name" come descritto in quel documento nonché le proprietà descritte in questo. Il termine si applica all'intero URI, comprese le sue componenti opzionali. Nota per il lettore: il termine "URN" è stato usato in altri contesti per riferirsi a un namespace URN, all'identificatore di namespace, all'assigned-name e a URI che non utilizzano lo schema "urn". Tutti questi usi tranne l'ultimo sono descritti con terminologia più specifica altrove in questo documento, ma, a causa di quegli altri usi, il termine va usato e interpretato con cautela.

Locator: un identificatore che fornisce un mezzo per accedere a una risorsa.

Sistema di identificatori: una raccolta gestita di nomi. Questo documento si riferisce ai sistemi di identificatori al di fuori del contesto degli URN come "sistemi di identificatori non URN".

Namespace URN: un sistema di identificatori associato a un NID di URN.

NID: l'identificatore associato a un namespace URN.

NSS: la parte di un URN specifica del namespace URN.

Assigned-name: la combinazione dello schema "urn:", del NID e della stringa specifica del namespace (NSS). Di conseguenza, un "assigned-name" è una sottostringa di un URN (come definito sopra) se tale URN contiene componenti aggiuntive (vedere la Sezione 2).

Il termine "name" deliberatamente non è definito qui e dovrebbe essere usato (e, in pratica, lo è) solo in modo molto informale. La RFC 3986 usa il termine come categoria di URI distinta dal "locator" (Sezione 1.1.3), ma lo usa anche in altri contesti. Se tali usi fossero trattati come definitori, entrerebbero in conflitto, ad esempio, con l'idea di nomi di namespace URN (cioè i NID) e con termini associati ai sistemi di identificatori non URN.

Questo documento usa i termini "resource", "identifier", "identify", "dereference", "representation" e "metadata" all'incirca come definiti nella specifica degli URI [RFC3986].

Questo documento usa i termini "resolution" e "resolver" all'incirca nel senso in cui erano usati nella discussione originale dei principi architetturali per gli URN [RFC2276], cioè la "resolution" è l'atto di fornire servizi relativi alla risorsa identificata, come tradurre l'URN persistente in uno o più locator correnti per la risorsa, fornire metadati sulla risorsa in un formato appropriato o persino fornire una rappresentazione della risorsa (ad esempio un documento) senza richiedere ulteriori intermediari. Al momento della stesura del presente documento, i servizi di risoluzione sono descritti nella [RFC2483].

Sulla distinzione tra rappresentazioni e metadati, vedere la Sezione 1.2.2 della [RFC3986].

Diversi altri termini relativi a operazioni di "normalization" che non fanno parte dello Standard Unicode [UNICODE] sono anch'essi usati qui come lo sono nella RFC 3986.

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nella [RFC2119].

1.2. Compromessi di progettazione

In misura molto maggiore rispetto a quando gli URN furono considerati per la prima volta e i loro usi delineati (vedere [RFC1737]), le questioni degli identificatori persistenti su Internet comportano compromessi di progettazione fondamentali che sono molto più ampi degli URN o dell'approccio URN e che toccano persino questioni di ricerca aperte all'interno della comunità delle scienze dell'informazione. Specifiche ideali e complete su ciò che dovrebbe essere fatto o richiesto nell'intero universo degli URN richiederebbero un accordo generale su un'ampia gamma di tali questioni e la loro soluzione. Sebbene alcune di queste questioni siano state introdotte dagli approcci di Internet o dell'era informatica alle codifiche dei caratteri e all'astrazione dei dati, altre precedono Internet e i sistemi informatici di secoli; è improbabile che si raggiunga un accordo su soluzioni complete nel prossimo futuro.

Sebbene di conseguenza questa specifica contenga alcuni requisiti e una certa flessibilità che non sarebbero presenti in un mondo più perfetto, ciò è stato necessario per produrre una specifica di consenso che fornisca una definizione modernizzata degli URN (l'alternativa poco attraente sarebbe stata quella di non modernizzare la definizione nonostante la diffusione capillare).

Le sottosezioni seguenti descrivono in maggiore dettaglio due delle questioni rilevanti.

1.2.1. Risoluzione

Una questione specifica degli URN (in contrapposizione ai sistemi di denominazione in generale) è il tema piuttosto difficile della "resolution", discusso nelle Sezioni 1.1, 2.3.1, 6.4.6 e altrove di seguito.

Con i tradizionali Uniform Resource Locator (URL), cioè con la maggior parte degli URI che sono locator, la risoluzione è relativamente semplice perché viene usata per determinare un meccanismo di accesso che a sua volta viene usato per dereferenziare il locator recuperando (tipicamente) una rappresentazione della risorsa associata, come un documento (vedere la Sezione 1.2.2 della [RFC3986]).

Al contrario, la risoluzione degli URN è più flessibile e variegata.

Un caso importante riguarda la mappatura di un URN su uno o più locator. In questo caso, il risultato finale è comunque questione di dereferenziare i locator mappati verso una o più rappresentazioni. La differenza principale qui è la persistenza: anche se un locator mappato è cambiato (ad esempio, un nome di dominio DNS ha cambiato proprietario e un URL non è stato modificato per puntare a una nuova posizione o, in un caso più estremo e ipotetico, il DNS viene sostituito del tutto), un utente di URN sarà in grado di ottenere la rappresentazione corretta (ad esempio un documento) purché il resolver abbia mantenuto aggiornate le sue mappature da URN a locator. Di conseguenza, le relazioni rilevanti possono essere definite in modo piuttosto preciso per gli URN che si risolvono in locator che a loro volta vengono dereferenziati verso una rappresentazione.

Tuttavia, questa specifica consente diversi altri casi di risoluzione degli URN, nonché URN per risorse che non coinvolgono sistemi di recupero di informazioni. Ciò vale sia individualmente per particolari URN sia (come definito di seguito) collettivamente per interi namespace URN.

Si consideri un namespace di URN che si risolvono in locator che a loro volta vengono dereferenziati solo verso metadati relativi alle risorse, perché i sistemi sottostanti non contengono rappresentazioni di tali risorse; un esempio potrebbe essere un namespace URN per gli International Standard Name Identifier (ISNI) così come quel sistema di identificatori è definito nello standard pertinente [ISO.27729.2012], in cui per impostazione predefinita un URN verrebbe risolto solo verso un record di metadati che descrive l'identità pubblica identificata dall'ISNI.

Si considerino anche gli URN che si risolvono in rappresentazioni solo se l'entità richiedente è autorizzata a ottenere la rappresentazione, mentre altre entità possono ottenere solo metadati sulla risorsa; un esempio potrebbero essere i documenti conservati nella raccolta del deposito legale di una biblioteca nazionale.

Infine, alcuni URN potrebbero non essere destinati affatto a risolversi in locator; esempi potrebbero includere URN che identificano nomi di namespace XML (ad esempio, il namespace URN "dgiwg" specificato dalla [RFC6288]), URN che identificano funzionalità applicative che possono essere supportate all'interno di un protocollo di comunicazione (ad esempio, il namespace URN "alert" specificato dalla [RFC7462]) e URN che identificano tipi enumerati come i valori in un registro (ad esempio, un namespace URN potrebbe essere usato per identificare individualmente i valori in tutti i registri IANA, come proposto in via provvisoria in [IANA-URN]).

I vari tipi di URN e i molteplici servizi di risoluzione che possono essere disponibili per essi rendono il concetto di "resolution" più complicato, ma anche molto più ricco per gli URN rispetto al caso semplice di risoluzione verso un locator che viene dereferenziato verso una rappresentazione.

1.2.2. Set di caratteri e codifiche

Un insieme simile di considerazioni si applica ai set di caratteri e alle codifiche. Gli URN, specialmente gli URN che saranno usati come identificatori rivolti all'utente, dovrebbero essere comodi da usare nelle lingue e nei sistemi di scrittura locali, facilmente specificabili con un'ampia gamma di tastiere e convenzioni locali, e non ambigui. Esistono compromessi tra questi obiettivi, ed è attualmente impossibile vedere come si potrebbe sviluppare un insieme di regole semplice e facilmente comprensibile che sia ottimale, o anche solo ragionevole, per tutti gli URN. La discussione nella Sezione 2.2 definisce un quadro generale che dovrebbe rendere possibile un'analisi e un'elaborazione generalizzate, ma formula anche raccomandazioni sulle regole per i singoli namespace URN.