6. Definizione e registrazione di un namespace URN

6.1. Panoramica

Poiché lo spazio dei namespace URN è esso stesso gestito, la definizione di un namespace URN DOVREBBE (SHOULD) prestare particolare attenzione a:

1. Lo scopo del namespace URN.

2. La sintassi degli URN assegnati all'interno del namespace URN, compresa la sintassi interna e gli effetti previsti degli r-component o dei q-component. (La sintassi e l'interpretazione degli f-component sono definite nella RFC 3986.)

3. Il processo di assegnazione degli URN all'interno del namespace URN.

4. Le implicazioni di sicurezza dell'assegnazione degli URN all'interno del namespace URN e dell'uso degli URN assegnati.

5. Eventuali problemi di interoperabilità potenziali con gli URN assegnati all'interno del namespace URN.

6. Facoltativamente, il processo di risoluzione degli URN assegnati all'interno del namespace URN.

La sezione sulla compilazione del modello (Sezione 6.4) spiega queste questioni in maggiore dettaglio. Sebbene i modelli di registrazione siano gli stessi in tutti i casi, procedure leggermente diverse sono usate a seconda della fonte della registrazione.

6.2. Politica e processo di registrazione: registrazioni della comunità

La politica di registrazione di base per i namespace URN è la Expert Review come definita nel documento sulle Considerazioni IANA [RFC5226]. Per i namespace URN o le loro definizioni che sono destinati a diventare standard o parti costitutive di standard, il risultato del processo di Expert Review è inteso come un rapporto, piuttosto che come istruzioni all'IANA di agire (vedere di seguito). I passaggi chiave sono:

1. Compilare il modello di registrazione del namespace URN (vedere la Sezione 6.4 e l'Appendice A). Ciò può essere fatto come parte di un Internet-Draft o di una specifica di un'altra serie, anche se ciò non è un requisito.

2. Inviare il modello compilato alla lista di discussione [email protected] per la revisione.

3. Se necessario per rispondere ai commenti ricevuti, ripetere i passaggi 1 e 2.

4. Se gli Esperti Designati approvano la richiesta e non è coinvolta alcuna azione di standardizzazione, l'IANA registrerà il NID richiesto. Se si prevede una standardizzazione, gli Esperti Designati prepareranno un rapporto e lo inoltreranno all'organismo di approvazione degli standard appropriato (l'IESG nel caso dell'IETF); l'IANA registrerà il NID richiesto solo dopo aver ricevuto indicazioni da tale organismo e una copia del rapporto di Expert Review.

Una registrazione di namespace URN può essere modificata aggiornando il modello di registrazione, seguendo gli stessi passaggi sopra delineati per le nuove registrazioni. Una registrazione modificata DEVE (MUST) descrivere le differenze rispetto alle versioni precedenti e DOVREBBE (SHOULD) annotare in modo particolare eventuali cambiamenti rilevanti nelle tecnologie sottostanti o nei processi di gestione del namespace URN.

L'esperienza maturata finora con le richieste di registrazione di namespace URN ha mostrato che i richiedenti a volte non comprendono inizialmente alcune delle sottigliezze dei namespace URN e che definire il namespace URN sotto forma di specifica consente ai richiedenti di formulare chiaramente il loro "contratto" con la comunità di utenti prevista. Pertanto, sebbene la politica di registrazione per i namespace URN formali sia la Expert Review e una specifica (distinta dal modello di registrazione) non sia strettamente richiesta, i richiedenti DOVREBBERO (SHOULD) fornire una specifica stabile che documenti la definizione del namespace URN e approfondisca le questioni qui descritte.

Poiché la denominazione può essere difficile e controversa, i richiedenti di namespace URN e gli Esperti Designati sono fortemente incoraggiati a lavorare insieme in uno spirito di buona fede e comprensione reciproca per raggiungere un consenso approssimativo (vedere [RFC7282]) sulla gestione delle richieste di registrazione. Sono anche incoraggiati a portare competenze aggiuntive nella discussione se ciò fosse utile a fornire una prospettiva o comunque a risolvere le questioni.

Soprattutto quando le iterazioni nel processo di registrazione si protraggono, ci si aspetta che gli Esperti Designati adottino ragionevoli precauzioni per evitare "race condition" sui NID proposti e, se tali situazioni si presentano, incoraggino i richiedenti a risolvere eventuali conflitti tra loro.

6.3. Politica e processo di registrazione: procedura rapida per organizzazioni di sviluppo di standard, società scientifiche e organismi simili

L'IETF riconosce che si presenteranno situazioni in cui saranno creati namespace URN per incorporare standard esistenti e consolidati, in particolare standard di identificatori, oppure per riflettere conoscenze, terminologie o metodi di organizzazione delle informazioni che esulano ampiamente dall'ambito dell'IETF o dalle probabili competenze in materia dei suoi Esperti Designati. Nelle situazioni in cui la richiesta di registrazione proviene da, o è autorizzata da, un'organizzazione di sviluppo di standard riconosciuta, una società scientifica o loro delegati, è disponibile una procedura alquanto diversa, a scelta di tale organismo:

1. Il modello di registrazione del namespace URN viene compilato e inviato come ai passaggi 1 e 2 della Sezione 6.2.

2. È richiesta una specifica che rifletta o faccia riferimento agli standard o alle specifiche esterne necessari. La pubblicazione nella Serie RFC o attraverso un processo IETF (ad esempio, la pubblicazione come Internet-Draft) non è prevista e sarebbe appropriata solo in circostanze molto insolite.

3. Le revisioni sulla lista di discussione e da parte degli Esperti Designati sono strettamente consultive, con le decisioni su quali consigli accettare e sulla durata da assegnare al processo strettamente sotto il controllo dell'organismo esterno.

4. Quando tale organismo conclude che la domanda è sufficientemente matura, il suo o i suoi rappresentanti richiederanno che l'IANA completi la registrazione del NID, e l'IANA lo farà.

Le decisioni su se riconoscere l'entità richiedente come organizzazione di sviluppo di standard o società scientifica sono responsabilità dell'IESG.

Un modello simile è già stato definito per le organizzazioni di sviluppo di standard riconosciute che desiderano registrare media type. Il documento che descrive tale meccanismo [RFC6838] fornisce qualche informazione in più sull'approccio generale.

6.4. Compilazione del modello

Un modello per definire e registrare un namespace URN è fornito nell'Appendice A. Questa sezione descrive le considerazioni per la compilazione del modello.

6.4.1. Scopo

La sezione "Scopo" del modello descrive questioni come:

1. I tipi di risorse identificate dagli URN assegnati all'interno del namespace URN.

2. L'ambito e l'applicabilità degli URN assegnati all'interno del namespace URN; ciò potrebbe includere informazioni sulla comunità di utilizzo (ad esempio, una particolare nazione, industria, tecnologia o organizzazione), se gli URN assegnati saranno usati su reti pubbliche o reti private, ecc.

3. In che modo la comunità prevista (e la comunità Internet nel suo complesso) trarrà beneficio dall'uso o dalla risoluzione degli URN assegnati.

4. In che modo il namespace URN si rapporta e si integra con i namespace URN, gli schemi URI e i sistemi di identificatori non URN esistenti.

5. I tipi di applicazioni software che possono usare o risolvere gli URN assegnati (ad esempio, differenziando tra namespace URN disparati, identificando le risorse in modo persistente o risolvendo e accedendo in modo significativo ai servizi associati al namespace URN).

6. Se i servizi di risoluzione sono disponibili o lo saranno (e, in tal caso, la natura o l'identità dei servizi). Esempi di semantica e sintassi del q-component e (quando sono standardizzati) dell'r-component sono utili in questo caso, anche se definizioni dettagliate sono fornite altrove o in seguito.

7. Se si prevede che il namespace URN o la sua definizione diventi parte costitutiva di uno standard in fase di sviluppo nell'IETF o in un altro organismo di standardizzazione riconosciuto.

6.4.2. Sintassi

La sezione "Sintassi" del modello contiene:

1. Una descrizione della struttura degli URN all'interno del namespace URN, in conformità con la sintassi fondamentale degli URN. La struttura potrebbe essere descritta in termini di una definizione formale (ad esempio, usando l'ABNF [RFC5234]), di un algoritmo per generare URN conformi o di un'espressione regolare per analizzare il nome nelle sue parti costitutive; in alternativa, la struttura potrebbe essere opaca.

2. Eventuali regole speciali di codifica dei caratteri per gli URN assegnati (ad esempio, quale carattere dovrebbe essere sempre usato per le virgolette).

3. Regole per determinare l'URN-equivalence tra due nomi nel namespace URN. Tali regole dovrebbero sempre avere l'effetto di eliminare i falsi negativi che altrimenti potrebbero derivare dal confronto. Se appropriato e utile, si può fare riferimento a particolari regole di equivalenza definite nella specifica degli URI [RFC3986] o alla Sezione 3 di questo documento. Esempi di regole di URN-equivalence includono l'equivalenza tra caratteri maiuscoli e minuscoli nell'NSS, tra raggruppamenti con e senza trattini nel nome, o tra virgolette singole e doppie. Possono anche esserci considerazioni speciali di codifica specifiche del namespace, specialmente per gli URN che contengono forme incorporate di nomi provenienti da sistemi di identificatori non URN. (Si noti che queste non sono affermazioni normative per alcun tipo di buona pratica relativa alla gestione delle relazioni tra caratteri in generale; tali affermazioni sono limitate a un solo particolare namespace URN.)

4. Eventuali considerazioni speciali necessarie per conformarsi alla sintassi degli URN. Ciò si applica in particolare nel caso di sistemi di identificatori non URN esistenti che sono usati nel contesto degli URN. Ad esempio, se un sistema di identificatori non URN è usato in contesti diversi dagli URN, potrebbe avvalersi di caratteri riservati nella sintassi degli URN. Questa sezione dovrebbe annotare tali caratteri e delineare le mappature necessarie per conformarsi alla sintassi degli URN. Normalmente, ciò sarà gestito codificando in percentuale il carattere come specificato nella Sezione 2.1 della specifica degli URI [RFC3986] e come discusso nella Sezione 1.2.2 di questa specifica.

5. Eventuali considerazioni speciali per il significato dei q-component (ad esempio, parole chiave) o degli f-component (ad esempio, termini predefiniti) nel contesto di questo namespace URN.

6.4.3. Assegnazione

La sezione "Assegnazione" del modello descrive questioni come:

1. Meccanismi o autorità per l'assegnazione degli URN alle risorse. Dovrebbe rendere chiaro se l'assegnazione è completamente aperta (ad esempio, seguendo una particolare procedura come first-come, first-served (FCFS)), completamente chiusa (ad esempio, per un'organizzazione privata) o limitata in vari modi (ad esempio, delegata ad autorità riconosciute da una particolare organizzazione); se limitata, dovrebbe spiegare come diventare assegnatari di nomi o come richiedere l'assegnazione di nomi da autorità di assegnazione esistenti.

2. Metodi per garantire che gli URN all'interno del namespace URN siano univoci. Ad esempio, i nomi potrebbero essere assegnati in modo sequenziale o secondo un processo ben definito da una singola autorità, l'assegnazione potrebbe essere suddivisa tra autorità delegate individualmente responsabili del rispetto delle regole di univocità, oppure gli URN potrebbero essere creati indipendentemente seguendo un algoritmo che garantisce esso stesso l'univocità.

6.4.4. Sicurezza e privacy

La sezione "Sicurezza e privacy" del modello descrive eventuali problemi potenziali relativi alla sicurezza e alla privacy per quanto riguarda l'assegnazione, l'uso e la risoluzione dei nomi all'interno del namespace URN. Esempi di tali problemi includono:

• Le conseguenze della produzione di falsi negativi e falsi positivi durante il confronto per l'URN-equivalence (vedere la Sezione 3.1 di questa specifica e "Issues in Identifier Comparison for Security Purposes" [RFC6943]).

• La fuga di informazioni private quando i nomi sono comunicati sulla Internet pubblica.

• Il potenziale di raccolta di informazioni dalle directory.

• Varie questioni discusse nelle linee guida per le considerazioni sulla sicurezza nelle RFC [RFC3552] e nelle considerazioni sulla privacy per i protocolli Internet [RFC6973]. In particolare, si noti il testo delle considerazioni sulla privacy per il namespace Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) [RFC7254], che può fornire un modello utile per tali casi.

6.4.5. Interoperabilità

La sezione "Interoperabilità" DEVE (MUST) specificare qualsiasi problema potenziale noto relativo all'interoperabilità. Gli esempi includono possibili confusioni con altri namespace URN, sistemi di identificatori non URN o schemi URI a causa della sintassi (ad esempio, la codifica percentuale di determinati caratteri) o dell'ambito (ad esempio, aree di interesse sovrapposte). Se possibile, le preoccupazioni che emergono durante la registrazione di un namespace URN (ad esempio, a causa della sintassi o dell'ambito di un sistema di identificatori non URN) dovrebbero essere risolte come parte del processo di registrazione o in parallelo ad esso.

6.4.6. Risoluzione

La sezione "Risoluzione" DEVE (MUST) specificare se meccanismi di risoluzione sono intesi o previsti per gli URN assegnati all'interno del namespace URN.

Se la risoluzione è intesa, questa sezione DOVREBBE (SHOULD) specificare se l'organizzazione che assegna URN all'interno del namespace URN intende gestire o raccomandare servizi di risoluzione per gli URN all'interno di quel namespace URN. Inoltre, se l'organizzazione assegnante intende implementare la registrazione per servizi di risoluzione pubblicamente pubblicizzati (ad esempio, usando un sistema sviluppato nello spirito dei principi architetturali e delle descrizioni dei servizi originali per la risoluzione degli URN [RFC2276] [RFC2483]), allora questa sezione DOVREBBE (SHOULD) elencare o fare riferimento ai requisiti per essere pubblicamente pubblicizzati dall'organizzazione assegnante. Inoltre, questa sezione DOVREBBE (SHOULD) descrivere eventuali considerazioni speciali per la gestione degli r-component nel contesto di questo namespace URN.

6.4.7. Informazioni aggiuntive

La sezione "Informazioni aggiuntive" include informazioni che sarebbero utili a chi cerca di comprendere questa registrazione o la sua relazione con altre registrazioni, come confronti con namespace URN esistenti che potrebbero sembrare sovrapporsi.

Questa sezione del modello è facoltativa.