2. Sintassi degli URN
Come discusso sopra, la sintassi degli URN in questa specifica consente una funzionalità significativamente maggiore rispetto alle specifiche precedenti, la più recente delle quali è la [RFC2141]. Essa è anche armonizzata con la sintassi generale degli URI [RFC3986] (che, va notato, è stata completata dopo le precedenti specifiche degli URN).
Tuttavia, questa specifica non estende la sintassi degli URN per consentire l'uso diretto di caratteri al di fuori dell'intervallo ASCII [RFC20]. Tale restrizione implica che qualsiasi carattere di questo tipo debba essere codificato in percentuale come descritto nella Sezione 2.1 della specifica degli URI [RFC3986].
La sintassi di base di un URN è definita usando la Augmented Backus-Naur Form (ABNF) come specificato nella [RFC5234]. Le regole non definite qui (nello specifico: alphanum, fragment e pchar) sono definite come parte della sintassi degli URI [RFC3986] e sono usate qui per evidenziare la relazione sintattica con i termini ivi usati. Le definizioni di alcuni dei termini usati di seguito non sono esaustive; restrizioni aggiuntive sono imposte dal testo in prosa che si trova nelle sezioni di questo documento specifiche per quei termini (specialmente r-component nella Sezione 2.3.1 e q-component nella Sezione 2.3.2).
namestring = assigned-name
[ rq-components ]
[ "#" f-component ]
assigned-name = "urn" ":" NID ":" NSS
NID = (alphanum) 0*30(ldh) (alphanum)
ldh = alphanum / "-"
NSS = pchar *(pchar / "/")
rq-components = [ "?+" r-component ]
[ "?=" q-component ]
r-component = pchar *( pchar / "/" / "?" )
q-component = pchar *( pchar / "/" / "?" )
f-component = fragment
Il carattere punto interrogativo "?" può essere usato senza codifica percentuale all'interno di r-component, q-component e f-component. Al di fuori di tali componenti, un "?" che non sia immediatamente seguito da "=" o "+" non è definito per gli URN e DOVREBBE (SHOULD) essere trattato come errore di sintassi dai parser specifici per URN e da altri processori.
Le sezioni seguenti forniscono informazioni aggiuntive sugli elementi sintattici degli URN.
2.1. Identificatore di namespace (NID)
I NID non distinguono tra maiuscole e minuscole (ad esempio, "ISBN" e "isbn" sono equivalenti).
I caratteri al di fuori dell'intervallo ASCII [RFC20] non sono consentiti nei NID, e nessun meccanismo di codifica per tali caratteri è supportato.
Le Sezioni 5.1 e 5.2 impongono vincoli aggiuntivi sulle stringhe che possono essere usate come NID, cioè la sintassi mostrata sopra non è esaustiva.
2.2. Stringa specifica del namespace (NSS)
L'NSS è una stringa, univoca all'interno di un namespace URN, che è assegnata e gestita in modo coerente e che è conforme alla definizione del namespace URN pertinente. La combinazione del NID (univoco in tutto lo schema "urn") e dell'NSS (univoco all'interno del namespace URN) garantisce che l'URN risultante sia globalmente univoco.
L'NSS come specificato in questo documento consente diversi caratteri non ammessi dalle specifiche precedenti (vedere l'Appendice B). In particolare, il carattere "/", ora consentito, rende effettivamente possibile incapsulare nomi gerarchici provenienti da sistemi di identificatori non URN. Per esempio, si consideri il caso ipotetico di un sistema di identificatori gerarchico in cui i nomi assumono la forma di una sequenza di numeri separati dal carattere "/", come "1/406/47452/2". Se l'autorità preposta a tali nomi usasse gli URN, sarebbe naturale collocare il nome esistente nell'NSS, ottenendo URN come "urn:example:1/406/47452/2".
Tali modifiche alla sintassi dell'NSS non modificano le regole di codifica per i namespace URN definiti in conformità con la [RFC2141]. Se un tale namespace URN, i cui nomi sono usati al di fuori del contesto URN (cioè in un sistema di identificatori non URN), consente anche l'uso di "/", "~" o "&" nella forma nativa all'interno di quel sistema di identificatori, allora le regole di codifica per quel namespace URN non vengono modificate da questa specifica.
A seconda delle regole che governano un sistema di identificatori non URN e il suo namespace URN associato, i nomi validi in quel sistema di identificatori potrebbero contenere caratteri non consentiti dalla produzione "pchar" a cui si fa riferimento sopra (ad esempio caratteri al di fuori dell'intervallo ASCII o, coerentemente con le restrizioni della RFC 3986, i caratteri "/", "?", "#", "[" e "]"). Sebbene un tale nome possa essere valido all'interno del sistema di identificatori non URN, non è un URN valido finché non è stato tradotto in un NSS conforme alle regole di quel particolare namespace URN. Nel caso di URN formati da nomi che esistono separatamente in un sistema di identificatori non URN, la traduzione di un nome dal suo formato "nativo" a un formato URN è realizzata usando i metodi di canonicalizzazione e codifica definiti per gli URN in generale o regole specifiche per quel namespace URN. Il software che non è a conoscenza delle regole di canonicalizzazione e codifica specifiche del namespace NON DEVE (MUST NOT) costruire URN dal nome nel sistema di identificatori non URN.
In particolare, per quanto riguarda i caratteri al di fuori dell'intervallo ASCII, gli URN che compaiono nei protocolli o che vengono passati tra sistemi DEVONO (MUST) usare solo caratteri Unicode codificati in UTF-8 e ulteriormente codificati come richiesto dalla RFC 3986. Nella misura in cui ciò è fattibile e coerente con i requisiti dei nomi definiti e standardizzati altrove, nonché con i principi discussi nella Sezione 1.2, i caratteri usati per rappresentare i nomi DOVREBBERO (SHOULD) essere limitati a lettere e cifre ASCII oppure ai caratteri e alla sintassi di alcuni modelli ampiamente usati come quelli di Internationalizing Domain Names in Applications (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) [RFC7613] o la specifica Unicode Identifier and Pattern Syntax [UAX31].
Al fine di rendere gli URN il più stabili e persistenti possibile quando i protocolli evolvono e l'ambiente circostante cambia, i namespace URN NON DOVREBBERO (SHOULD NOT) consentire caratteri al di fuori dell'intervallo ASCII [RFC20], a meno che la natura del particolare namespace URN non renda tali caratteri necessari.
2.3. Componenti opzionali
Questa specifica include tre componenti opzionali nella sintassi degli URN. Sono note come r-component, q-component e f-component e sono descritte più dettagliatamente di seguito. Poiché questa specifica si concentra quasi esclusivamente sulla sintassi degli URN, non definisce semantiche dettagliate di queste componenti per gli URN in generale. Tuttavia, ciascuna di queste componenti ha un ruolo distinto che è indipendente da qualsiasi URN dato e dal suo namespace URN. Si intende che i client siano in grado di gestire queste componenti in modo uniforme per tutti gli URN. Queste componenti POSSONO (MAY) essere usate con URN provenienti da namespace URN esistenti, indipendentemente dal fatto che un namespace URN le supporti esplicitamente o meno. Tuttavia, coerentemente con l'approccio adottato nella RFC 3986, il comportamento di un URN che contiene componenti non definite o prive di significato per un particolare namespace URN o risorsa non è definito. Le sezioni seguenti descrivono queste componenti opzionali e la loro interpretazione in maggiore dettaglio.
2.3.1. r-component
L'r-component è destinata a passare parametri ai servizi di risoluzione degli URN (intesi in senso ampio, vedere la Sezione 1.2) ed è interpretata da tali servizi. (Al contrario, il passaggio di parametri alle risorse identificate da un URN, o alle applicazioni che gestiscono tali risorse, è gestito dai q-component come descritto nella sezione successiva.)
L'r-component degli URN non ha alcun corrispettivo sintattico in nessun altro schema URI noto.
La sequenza "?+" introduce l'r-component. L'r-component termina con una sequenza "?=" (che dà inizio a un q-component) o con un carattere "#" (segno di numero, che dà inizio a un f-component). Se nessuno dei due compare, l'r-component continua fino alla fine dell'URN. Si noti che i caratteri al di fuori dell'intervallo ASCII [RFC20] DEVONO (MUST) essere codificati in percentuale usando il metodo definito nella Sezione 2.1 della specifica generica degli URI [RFC3986].
Come descritto nella Sezione 3, l'r-component NON DEVE (SHALL NOT) essere presa in considerazione nel determinare l'URN-equivalence. Tuttavia, l'r-component DEVE (SHALL) essere fornita insieme all'URN quando si presenta una richiesta a un servizio di risoluzione degli URN.
Questo documento definisce solo la sintassi dell'r-component e la riserva a usi futuri. La semantica esatta dell'r-component e il suo uso nei protocolli di risoluzione degli URN sono materia di potenziale standardizzazione in specifiche separate, presumibilmente comprese specifiche che definiscono convenzioni e un registro per gli identificatori dei servizi di risoluzione.
Si consideri l'esempio ipotetico di passaggio di parametri a un servizio di risoluzione (diciamo, un codice paese ISO alpha-2 [ISO.3166-1] per selezionare il paese preferito in cui cercare una copia fisica di un libro). Ciò potrebbe forse essere realizzato specificando il codice paese nell'r-component, ottenendo URN come:
urn:example:foo-bar-baz-qux?+CCResolve:cc=uk
Sebbene quanto sopra dovrebbe servire come spiegazione generale e illustrazione dell'intento degli r-component, vi sono molte questioni aperte al riguardo, compresa la loro relazione con i meccanismi di risoluzione associati al particolare namespace URN al momento della registrazione. Pertanto, gli r-component NON DOVREBBERO (SHOULD NOT) essere usati per gli URN prima che la loro semantica sia stata standardizzata.
2.3.2. q-component
Il q-component è destinato a passare parametri o alla risorsa denominata o a un sistema che può fornire il servizio richiesto, affinché siano interpretati da quella risorsa o da quel sistema. (Al contrario, il passaggio di parametri ai servizi di risoluzione degli URN è gestito dagli r-component come descritto nella sezione precedente.)
Il q-component degli URN ha la stessa sintassi della componente di query di un URI, ma è introdotto da "?=", non dal solo "?". Per un URN che può essere risolto in un URI che è un locator, la semantica del q-component è identica a quella della componente di query di quell'URI. Pertanto, i resolver di URN che restituiscono un URI che è un locator per un URN con un q-component fanno ciò copiando il q-component dall'URN alla componente di query dell'URI. Un esempio dell'operazione di copia è riportato di seguito.
Questa specifica non prescrive un comportamento richiesto nel caso di risoluzione di un URN in un URI che è un locator quando l'URN originale ha un q-component e l'URI ha una stringa di query. Circostanze diverse possono richiedere approcci diversi. I resolver DOVREBBERO (SHOULD) documentare la loro strategia in tali casi.
Se l'URN non si risolve in un URI che è un locator, l'interpretazione del q-component non è definita da questa specifica. Per gli URN che possono essere risolti in un URI che è un locator, la semantica del q-component è identica a quella delle query alla risorsa individuata tramite quell'URI.
Per coerenza con la RFC 3986, la sintassi generale e la semantica dei q-component non sono definite da, né dipendono da, il namespace URN dell'URN. Parallelamente alla RFC 3986, i dettagli della sintassi e della semantica, ad esempio quali parole chiave o termini siano significativi, possono naturalmente dipendere da un particolare namespace URN o persino da una particolare risorsa.
La sequenza "?=" introduce il q-component. Il q-component termina con un carattere "#" (segno di numero, che dà inizio a un f-component). Se tale carattere non compare, il q-component continua fino alla fine dell'URN. I caratteri barra ("/") e punto interrogativo ("?") possono rappresentare dati all'interno del q-component. Si noti che i caratteri al di fuori dell'intervallo ASCII [RFC20] DEVONO (MUST) essere codificati in percentuale usando il metodo definito nella Sezione 2.1 della specifica generica degli URI [RFC3986].
Come descritto nella Sezione 3, il q-component NON DEVE (SHALL NOT) essere preso in considerazione nel determinare l'URN-equivalence.
I namespace URN e la relativa collocazione delle informazioni nella sintassi DOVREBBERO (SHOULD) essere progettati per evitare qualsiasi necessità che un servizio di risoluzione consideri il q-component. I sistemi di risoluzione specifici del namespace e quelli più generici NON DEVONO (MUST NOT) richiedere che le informazioni del q-component siano loro trasmesse per l'elaborazione.
Si consideri l'esempio ipotetico di passaggio di parametri a un'applicazione che restituisce bollettini meteorologici da regioni diverse o per periodi di tempo diversi. Ciò potrebbe forse essere realizzato specificando coordinate di latitudine e longitudine e date/ore nel q-component dell'URN, ottenendo URN come i seguenti.
urn:example:weather?=op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
Se questo esempio si risolvesse in un URI HTTP, il risultato potrebbe essere simile a:
https://weatherapp.example?op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
2.3.3. f-component
L'f-component è destinata a essere interpretata dal client come specifica di una posizione all'interno della risorsa denominata, o di una sua regione. Essa distingue le parti costitutive di una risorsa denominata da un URN. Per un URN che si risolve in uno o più locator che possono essere dereferenziati verso una rappresentazione, o quando il resolver di URN restituisce direttamente una rappresentazione della risorsa, la semantica di un f-component è definita dal media type della rappresentazione.
L'f-component degli URN ha la stessa sintassi della componente di frammento di un URI. Se un URN contenente un f-component si risolve in un singolo URI che è un locator associato alla risorsa denominata, l'f-component dell'URN può essere applicata (di solito dal client) come frammento di quell'URI. Se l'URN non si risolve in un URI che è un locator, l'interpretazione dell'f-component non è definita da questa specifica. Pertanto, per gli URN che possono essere risolti in un URI che è un locator, la semantica degli f-component è identica a quella dei frammenti per quella risorsa.
Per coerenza con la RFC 3986, né la sintassi generale né la semantica degli f-component sono definite da, né dipendono da, il namespace URN dell'URN. Parallelamente alla RFC 3986, i dettagli della sintassi e della semantica, ad esempio quali parole chiave o termini siano significativi, possono naturalmente dipendere da un particolare namespace URN o persino da una particolare risorsa.
L'f-component è introdotta dal carattere segno di numero ("#") e terminata dalla fine dell'URI. Qualsiasi carattere al di fuori dell'intervallo ASCII [RFC20] che compaia nell'f-component DEVE (MUST) essere codificato in percentuale usando il metodo definito nella Sezione 2.1 della specifica generica degli URI [RFC3986].
Come descritto nella Sezione 3, l'f-component NON DEVE (SHALL NOT) essere presa in considerazione nel determinare l'URN-equivalence.
I client NON DOVREBBERO (SHOULD NOT) passare gli f-component ai servizi di risoluzione, a meno che tali servizi svolgano anche funzioni di recupero e interpretazione dell'oggetto.
Si consideri l'esempio ipotetico di ottenere risorse che fanno parte di un'entità più grande (diciamo, i capitoli di un libro). Ogni parte potrebbe essere specificata nell'f-component, ottenendo URN come:
urn:example:foo-bar-baz-qux#somepart