Passa al contenuto principale

3. URI ben noti

3. URI ben noti

Un URI ben noto (well-known URI) è un URI [RFC3986] il cui componente di percorso inizia con i caratteri /.well-known/, a condizione che lo schema sia esplicitamente definito per supportare gli URI ben noti.

Ad esempio, se un’applicazione registra il nome example, l’URI ben noto corrispondente su http://www.example.com/ sarebbe http://www.example.com/.well-known/example.

Questa specifica aggiorna gli schemi http [RFC7230] e https [RFC7230] per supportare gli URI ben noti. Altri schemi esistenti possono usare il processo appropriato per aggiornare le definizioni; ad esempio [RFC8307] lo fa per gli schemi ws e wss. Il registro « Uniform Resource Identifier (URI) Schemes » tiene traccia di quali schemi supportano gli URI ben noti; vedere la sezione 5.2.

Le applicazioni che intendono introdurre nuovi URI ben noti MUST registrarli seguendo le procedure della sezione 5.1, soggette ai requisiti seguenti.

I nomi registrati MUST conformarsi alla produzione segment-nz in [RFC3986]. Ciò significa che non possono contenere il carattere /.

I nomi registrati per un’applicazione specifica SHOULD essere di conseguenza precisi; non è incoraggiato « occupare » termini generici. Ad esempio, se l’applicazione Example desidera una posizione ben nota per i metadati, un nome registrato appropriato potrebbe essere example-metadata o persino example.com-metadata, non metadata.

Come minimo, una registrazione farà riferimento a una specifica che definisce il formato e il o i tipi di media (media type) ottenuti dereferenziando l’URI ben noto, insieme agli schemi URI con cui l’URI ben noto può essere usato. Se nessuno schema URI è specificato esplicitamente, si assume http e https.

In genere le applicazioni useranno la porta predefinita per lo schema dato; se si usa una porta alternativa, MUST essere esplicitamente specificata dall’applicazione interessata.

Le registrazioni MAY includere anche informazioni aggiuntive, come la sintassi di ulteriori componenti di percorso, stringhe di query e/o identificatori di frammento da appendere all’URI ben noto, o dettagli specifici del protocollo (ad es. gestione dei metodi HTTP [RFC7231]).

Si noti che questa specifica non definisce come determinare il nome host da usare per trovare l’URI ben noto per una particolare applicazione, né l’ambito dei metadati scoperti dereferenziando l’URI ben noto; entrambi dovrebbero essere definiti dall’applicazione stessa.

Inoltre questa specifica non definisce un formato o un tipo di media per la risorsa situata in /.well-known/, e i client non dovrebbero aspettarsi che esista una risorsa in quella posizione.

Gli URI ben noti sono radicati alla sommità della gerarchia del percorso; per definizione non sono « ben noti » in altre parti del percorso. Ad esempio /.well-known/example è un URI ben noto, mentre /foo/.well-known/example non lo è.

Vedere anche la sezione 4 per le considerazioni di sicurezza relative alle posizioni ben note.

3.1. Registrazione degli URI ben noti

Il registro « Well-Known URIs » si trova presso https://www.iana.org/assignments/well-known-uris/. Le richieste di registrazione possono essere inviate seguendo le istruzioni ivi contenute o inviando un messaggio alla mailing list [email protected].

Le richieste di registrazione comprendono almeno le seguenti informazioni:

URI suffix: il nome richiesto per l’URI ben noto, relativo a /.well-known/; ad es. example.

Change controller: per le RFC Standards Track, indicare « IETF ». Negli altri casi, indicare il nome della parte responsabile. Possono essere inclusi altri dettagli (ad es. indirizzo email, URI della home page).

Specification document(s): riferimento al documento che specifica il campo, preferibilmente con un URI da cui ottenere una copia. Può essere inclusa un’indicazione delle sezioni rilevanti, ma non è obbligatoria.

Status: uno tra permanent o provisional. Vedere le indicazioni sotto.

Related information: facoltativamente, citazioni ad altri documenti con ulteriori informazioni pertinenti.

I requisiti generali per i valori registrati sono descritti nella sezione 3.

I valori definiti da RFC Standards Track e altri standard aperti (nel senso di [RFC2026], sezione 7.1.1) hanno stato permanent. Altri valori possono essere registrati come permanenti se gli esperti, in consultazione con la comunità, ritengono che siano in uso. Altri valori dovrebbero essere registrati come provisional.

Le voci provvisorie possono essere rimosse dagli esperti se, in consultazione con la comunità, ritengono che non siano in uso. Gli esperti possono cambiare lo stato di una voce provvisoria in permanente; nel farlo dovrebbero considerare quanto sia diffuso un valore e consultare in anticipo la comunità.

La « consultazione della comunità » di cui sopra si riferisce a chi è responsabile del o degli schemi URI in questione. In genere avviene sulle mailing list del gruppo di lavoro appropriato (anche concluso), o su [email protected] se tale lista non esiste.

Gli URI ben noti possono essere registrati da terze parti (inclusi gli esperti) se gli esperti ritengono che un URI ben noto non registrato sia ampiamente distribuito e che altrimenti non sia probabile una registrazione tempestiva. Tali registrazioni restano soggette ai requisiti definiti, inclusa la necessità di riferire una specifica.