16. Extending HTTP (Estensione di HTTP)

HTTP definisce una serie di punti di estensione generici che possono essere utilizzati per introdurre capacità nel protocollo senza introdurre una nuova versione, inclusi metodi, codici di stato, nomi di campi e ulteriori punti di estensibilità all'interno di campi definiti, come schemi di autenticazione e direttive di cache (vedere le estensioni Cache-Control nella Sezione 5.2.3 di [CACHING]). Poiché la semantica di HTTP non è versionata, questi punti di estensione sono persistenti; la versione del protocollo in uso non ne influenza la semantica.

Le estensioni indipendenti dalla versione sono scoraggiate dal dipendere o interagire con la versione specifica del protocollo in uso. Quando ciò è inevitabile, è necessario considerare attentamente come l'estensione possa interoperare tra le versioni.

Inoltre, versioni specifiche di HTTP potrebbero avere i propri punti di estensibilità, come le codifiche di trasferimento in HTTP/1.1 (Sezione 6.1 di [HTTP/1.1]) e i SETTINGS HTTP/2 o i tipi di frame ([HTTP/2]). Questi punti di estensione sono specifici della versione del protocollo in cui si verificano.

Le estensioni specifiche della versione non possono sovrascrivere o modificare la semantica di un meccanismo o punto di estensione indipendente dalla versione (come un metodo o un campo header) senza essere esplicitamente autorizzate da quell'elemento di protocollo. Ad esempio, il metodo CONNECT (Sezione 9.3.6) lo consente.

Queste linee guida assicurano che il protocollo funzioni correttamente e in modo prevedibile, anche quando parti del percorso implementano versioni diverse di HTTP.

16.1. Method Extensibility (Estensibilità dei metodi)

16.1.1. Method Registry (Registro dei metodi)

Il "Hypertext Transfer Protocol (HTTP) Method Registry", mantenuto da IANA all'indirizzo https://www.iana.org/assignments/http-methods, registra i nomi dei metodi.

Le registrazioni dei metodi HTTP DEVONO includere i seguenti campi:

• Method Name (Nome del metodo) (vedere Sezione 9)
• Safe ("yes" o "no", vedere Sezione 9.2.1)
• Idempotent ("yes" o "no", vedere Sezione 9.2.2)
• Pointer to specification text (Puntatore al testo di specifica)

I valori da aggiungere a questo namespace richiedono una revisione IETF (vedere [RFC8126], Sezione 4.8).

16.1.2. Considerations for New Methods (Considerazioni per i nuovi metodi)

I metodi standardizzati sono generici; cioè, sono potenzialmente applicabili a qualsiasi risorsa, non solo a un particolare tipo di media, tipo di risorsa o applicazione. Pertanto, è preferibile che i nuovi metodi siano registrati in un documento che non sia specifico per una singola applicazione o formato di dati, poiché le tecnologie ortogonali meritano specifiche ortogonali.

Poiché il parsing dei messaggi (Sezione 6) deve essere indipendente dalla semantica del metodo (a parte le risposte a HEAD), le definizioni di nuovi metodi non possono modificare l'algoritmo di parsing o proibire la presenza di contenuto sul messaggio di richiesta o di risposta. Le definizioni di nuovi metodi possono specificare che è consentito solo un contenuto di lunghezza zero richiedendo un campo header Content-Length con un valore di "0".

Allo stesso modo, i nuovi metodi non possono utilizzare le forme speciali host:port e asterisco del target di richiesta che sono consentite per CONNECT e OPTIONS, rispettivamente (Sezione 7.1). È necessario un URI completo in forma assoluta per l'URI target, il che significa che il target di richiesta deve essere inviato in forma assoluta oppure l'URI target verrà ricostruito dal contesto di richiesta nello stesso modo in cui avviene per altri metodi.

Una nuova definizione di metodo deve indicare se è sicuro (Sezione 9.2.1), idempotente (Sezione 9.2.2), memorizzabile nella cache (Sezione 9.2.3), quale semantica deve essere associata al contenuto della richiesta (se presente) e quali raffinamenti il metodo apporta alla semantica del campo header o del codice di stato. Se il nuovo metodo è memorizzabile nella cache, la sua definizione dovrebbe descrivere come, e in quali condizioni, una cache può memorizzare una risposta e utilizzarla per soddisfare una richiesta successiva. Il nuovo metodo dovrebbe descrivere se può essere reso condizionale (Sezione 13.1) e, in tal caso, come risponde un server quando la condizione è falsa. Allo stesso modo, se il nuovo metodo potrebbe avere una qualche utilità per la semantica di risposta parziale (Sezione 14.2), dovrebbe documentarlo anche.

Nota: Evitare di definire nomi di metodo che iniziano con "M-", poiché quel prefisso potrebbe essere interpretato erroneamente come avente la semantica assegnatagli da [RFC2774].

16.2. Status Code Extensibility (Estensibilità dei codici di stato)

16.2.1. Status Code Registry (Registro dei codici di stato)

Il "Hypertext Transfer Protocol (HTTP) Status Code Registry", mantenuto da IANA all'indirizzo https://www.iana.org/assignments/http-status-codes, registra i numeri dei codici di stato.

Una registrazione DEVE includere i seguenti campi:

• Status Code (Codice di stato) (3 cifre)
• Short Description (Descrizione breve)
• Pointer to specification text (Puntatore al testo di specifica)

I valori da aggiungere al namespace dei codici di stato HTTP richiedono una revisione IETF (vedere [RFC8126], Sezione 4.8).

16.2.2. Considerations for New Status Codes (Considerazioni per i nuovi codici di stato)

Quando è necessario esprimere una semantica per una risposta che non è definita dai codici di stato attuali, può essere registrato un nuovo codice di stato. I codici di stato sono generici; sono potenzialmente applicabili a qualsiasi risorsa, non solo a un particolare tipo di media, tipo di risorsa o applicazione HTTP. Pertanto, è preferibile che i nuovi codici di stato siano registrati in un documento che non sia specifico per una singola applicazione.

I nuovi codici di stato devono rientrare in una delle categorie definite nella Sezione 15. Per consentire ai parser esistenti di elaborare il messaggio di risposta, i nuovi codici di stato non possono proibire il contenuto, sebbene possano imporre un contenuto di lunghezza zero.

Le proposte per nuovi codici di stato che non sono ancora ampiamente distribuiti dovrebbero evitare di allocare un numero specifico per il codice fino a quando non c'è un chiaro consenso che verrà registrato; invece, le prime bozze possono utilizzare una notazione come "4NN" o "3N0" .. "3N9" per indicare la classe del/dei codice/i di stato proposto/i senza consumare prematuramente un numero.

La definizione di un nuovo codice di stato dovrebbe spiegare le condizioni di richiesta che causerebbero una risposta contenente quel codice di stato (ad esempio, combinazioni di campi header di richiesta e/o metodo/i) insieme a eventuali dipendenze dai campi header di risposta (ad esempio, quali campi sono richiesti, quali campi possono modificare la semantica e quale semantica del campo viene ulteriormente raffinata quando utilizzata con il nuovo codice di stato).

Per impostazione predefinita, un codice di stato si applica solo alla richiesta corrispondente alla risposta in cui si verifica. Se un codice di stato si applica a un ambito di applicabilità più ampio -- ad esempio, tutte le richieste alla risorsa in questione o tutte le richieste a un server -- ciò DEVE essere specificato esplicitamente. Nel fare ciò, va notato che non tutti i client applicheranno in modo coerente un ambito più ampio perché potrebbero non comprendere il nuovo codice di stato.

La definizione di un nuovo codice di stato finale dovrebbe specificare se è euristicamente memorizzabile nella cache o meno. Si noti che qualsiasi risposta con un codice di stato finale può essere memorizzata nella cache se ha informazioni esplicite sulla freschezza. Un codice di stato definito come euristicamente memorizzabile nella cache è autorizzato a essere memorizzato nella cache senza informazioni esplicite sulla freschezza. Allo stesso modo, la definizione di un codice di stato può imporre vincoli sul comportamento della cache se viene utilizzata la direttiva di cache must-understand. Vedere [CACHING] per ulteriori informazioni.

Infine, la definizione di un nuovo codice di stato dovrebbe indicare se il contenuto ha un'associazione implicita con una risorsa identificata (Sezione 6.4.2).

16.3. Field Extensibility (Estensibilità dei campi)

Il punto di estensibilità più ampiamente utilizzato di HTTP è la definizione di nuovi campi header e trailer.

È possibile definire nuovi campi in modo tale che, quando sono compresi da un destinatario, sovrascrivano o migliorino l'interpretazione di campi precedentemente definiti, definiscano precondizioni sulla valutazione della richiesta o affinino il significato delle risposte.

Tuttavia, la definizione di un campo non garantisce la sua distribuzione o il suo riconoscimento da parte dei destinatari. La maggior parte dei campi è progettata con l'aspettativa che un destinatario possa tranquillamente ignorare (ma inoltrare a valle) qualsiasi campo non riconosciuto. In altri casi, la capacità del mittente di comprendere un dato campo potrebbe essere indicata dalla sua comunicazione precedente, forse nella versione del protocollo o nei campi che ha inviato in messaggi precedenti, o dal suo uso di un tipo di media specifico. Allo stesso modo, l'ispezione diretta del supporto potrebbe essere possibile tramite una richiesta OPTIONS o interagendo con un URI well-known definito [RFC8615] se tale ispezione è definita insieme al campo introdotto.

16.3.1. Field Name Registry (Registro dei nomi dei campi)

Il "Hypertext Transfer Protocol (HTTP) Field Name Registry" definisce il namespace per i nomi dei campi HTTP.

Qualsiasi parte può richiedere la registrazione di un campo HTTP. Vedere la Sezione 16.3.2 per le considerazioni da tenere in considerazione quando si crea un nuovo campo HTTP.

Il "Hypertext Transfer Protocol (HTTP) Field Name Registry" si trova all'indirizzo https://www.iana.org/assignments/http-fields/. Le richieste di registrazione possono essere effettuate seguendo le istruzioni situate lì o inviando un'email alla mailing list "[email protected]".

I nomi dei campi sono registrati su consiglio di un esperto designato (nominato dall'IESG o dal suo delegato). I campi con lo stato 'permanent' richiedono una specifica (Specification Required) ([RFC8126], Sezione 4.6).

Le richieste di registrazione consistono nelle seguenti informazioni:

Field name (Nome del campo): Il nome del campo richiesto. DEVE conformarsi alla sintassi field-name definita nella Sezione 5.1 e DOVREBBE essere limitato a soli lettere, cifre e caratteri trattino ('-'), con il primo carattere che è una lettera.

Status (Stato): "permanent", "provisional", "deprecated" o "obsoleted".

Specification document(s) (Documento/i di specifica): Un riferimento al documento che specifica il campo, preferibilmente includendo un URI che può essere utilizzato per recuperare una copia del documento. Può anche essere inclusa un'indicazione delle sezioni pertinenti, ma non è richiesta.

E opzionalmente:

Comments (Commenti): Informazioni aggiuntive, come informazioni sulle voci riservate.

L'esperto/gli esperti può/possono definire campi aggiuntivi da raccogliere nel registro, in consultazione con la comunità.

I nomi definiti dagli standard hanno uno stato "permanent". Altri nomi possono anche essere registrati come permanenti se l'esperto/gli esperti rileva/rilevano che sono in uso e, in consultazione con la comunità, l'esperto/gli esperti li considera/considerano appropriati. Gli altri nomi DOVREBBERO essere registrati come "provisional".

Le voci provvisorie possono essere rimosse dall'esperto/dagli esperti se, in consultazione con la comunità, l'esperto/gli esperti rileva/rilevano che non sono in uso. L'esperto/Gli esperti può/possono modificare lo stato di una voce provvisoria in permanente in qualsiasi momento.

Si noti che i nomi possono essere registrati da terze parti (incluso l'esperto/gli esperti), se l'esperto/gli esperti determina/determinano che un nome non registrato è ampiamente distribuito e non è probabile che venga registrato in modo tempestivo.

16.3.2. Considerations for New Fields (Considerazioni per i nuovi campi)

I campi header e trailer HTTP sono un punto di estensione ampiamente utilizzato per il protocollo. Sebbene possano essere utilizzati in modo ad hoc, i campi destinati a un uso più ampio devono essere attentamente documentati per garantire l'interoperabilità.

In particolare, agli autori di specifiche che definiscono nuovi campi si consiglia di considerare e, ove appropriato, documentare i seguenti aspetti:

• In quali condizioni il campo può essere utilizzato; ad esempio, solo nelle risposte o richieste, in tutti i messaggi, solo nelle risposte a un particolare metodo di richiesta, ecc.

• Se la semantica del campo è ulteriormente raffinata dal suo contesto, come il suo uso con determinati metodi di richiesta o codici di stato.

• L'ambito di applicabilità per le informazioni trasmesse. Per impostazione predefinita, i campi si applicano solo al messaggio a cui sono associati, ma alcuni campi di risposta sono progettati per applicarsi a tutte le rappresentazioni di una risorsa, alla risorsa stessa o a un ambito ancora più ampio. Le specifiche che espandono l'ambito di un campo di risposta dovranno considerare attentamente questioni come la negoziazione del contenuto, il periodo di tempo di applicabilità e (in alcuni casi) le distribuzioni di server multi-tenant.

• In quali condizioni gli intermediari sono autorizzati a inserire, eliminare o modificare il valore del campo.

• Se il campo è consentito nei trailer; per impostazione predefinita, non lo sarà (vedere Sezione 6.5.1).

• Se è appropriato o addirittura richiesto elencare il nome del campo nel campo header Connection (cioè, se il campo è hop-by-hop; vedere Sezione 7.6.1).

• Se il campo introduce considerazioni di sicurezza aggiuntive, come la divulgazione di dati relativi alla privacy.

I campi header di richiesta che desiderano consentire un comportamento diverso da quello predefinito hanno considerazioni aggiuntive da documentare:

• Se è appropriato elencare il nome del campo nel campo header di risposta Vary (ad esempio, quando l'algoritmo di selezione del contenuto del server di origine utilizza il campo header di richiesta; vedere Sezione 12.5.5).

• Se il campo è destinato a essere memorizzato da un server quando ricevuto in una richiesta PUT (vedere Sezione 9.3.4).

• Se il campo dovrebbe essere rimosso quando si reindirizza automaticamente una richiesta a causa di problemi di sicurezza (vedere Sezione 15.4).

16.3.2.1. Considerations for New Field Names (Considerazioni per i nuovi nomi dei campi)

Agli autori di specifiche che definiscono nuovi campi si consiglia di scegliere un nome di campo breve ma descrittivo. I nomi brevi evitano la trasmissione di dati non necessari; i nomi descrittivi evitano confusione e "occupazione" di nomi che potrebbero avere usi più ampi.

A tal fine, i campi di uso limitato (come un header confinato a una singola applicazione o caso d'uso) sono incoraggiati a utilizzare un nome che includa tale uso (o un'abbreviazione) come prefisso; ad esempio, se l'applicazione Foo necessita di un campo Description, potrebbe utilizzare "Foo-Desc"; "Description" è troppo generico e "Foo-Description" è inutilmente lungo.

Sebbene la sintassi field-name sia definita per consentire qualsiasi carattere token, in pratica alcune implementazioni pongono limiti sui caratteri che accettano nei nomi dei campi. Per essere interoperabili, i nuovi nomi dei campi DOVREBBERO limitarsi a caratteri alfanumerici, "-" e "." e DOVREBBERO iniziare con una lettera. Ad esempio, il carattere underscore ("_") può essere problematico quando passato attraverso interfacce gateway non HTTP (vedere Sezione 17.10).

I nomi dei campi non dovrebbero essere preceduti da "X-"; vedere [BCP178] per ulteriori informazioni.

Altri prefissi vengono talvolta utilizzati nei nomi dei campi HTTP; ad esempio, "Accept-" è utilizzato in molti header di negoziazione del contenuto e "Content-" è utilizzato come spiegato nella Sezione 6.4. Questi prefissi sono solo un aiuto per riconoscere lo scopo di un campo e non attivano l'elaborazione automatica.

16.3.2.2. Considerations for New Field Values (Considerazioni per i nuovi valori dei campi)

Un compito importante nella definizione di un nuovo campo HTTP è la specifica della sintassi del valore del campo: cosa dovrebbero generare i mittenti e come i destinatari dovrebbero inferire la semantica da ciò che viene ricevuto.

Gli autori sono incoraggiati (ma non obbligati) a utilizzare le regole ABNF in questa specifica o quelle in [RFC8941] per definire la sintassi dei nuovi valori dei campi.

Si consiglia agli autori di considerare attentamente come la combinazione di più righe di campo li influenzerà (vedere Sezione 5.3). Poiché i mittenti potrebbero erroneamente inviare più valori, e sia gli intermediari che le librerie HTTP possono eseguire la combinazione automaticamente, ciò si applica a tutti i valori dei campi -- anche quando è previsto un solo valore.

Pertanto, si consiglia agli autori di delimitare o codificare i valori che contengono virgole (ad esempio, con la regola quoted-string della Sezione 5.6.4, il tipo di dati String di [RFC8941] o una codifica specifica del campo). Ciò garantisce che le virgole all'interno dei dati del campo non siano confuse con le virgole che delimitano un valore di elenco.

Ad esempio, il valore del campo Content-Type consente le virgole solo all'interno di stringhe tra virgolette, che possono essere analizzate in modo affidabile anche quando sono presenti più valori. Il valore del campo Location fornisce un controesempio che non dovrebbe essere emulato: poiché gli URI possono includere virgole, non è possibile distinguere in modo affidabile tra un singolo valore che include una virgola e due valori.

Gli autori di campi con valori singleton (vedere Sezione 5.5) sono inoltre invitati a documentare come deve essere gestito un messaggio che contiene più membri (un valore predefinito ragionevole sarebbe ignorare il campo, ma potrebbe non essere sempre la scelta corretta).

16.4. Authentication Scheme Extensibility (Estensibilità degli schemi di autenticazione)

16.4.1. Authentication Scheme Registry (Registro degli schemi di autenticazione)

Il "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" definisce il namespace per gli schemi di autenticazione nelle challenge e nelle credenziali. È mantenuto all'indirizzo https://www.iana.org/assignments/http-authschemes.

Le registrazioni DEVONO includere i seguenti campi:

• Authentication Scheme Name (Nome dello schema di autenticazione)
• Pointer to specification text (Puntatore al testo di specifica)
• Notes (Note) (opzionale)

I valori da aggiungere a questo namespace richiedono una revisione IETF (vedere [RFC8126], Sezione 4.8).

16.4.2. Considerations for New Authentication Schemes (Considerazioni per i nuovi schemi di autenticazione)

Ci sono alcuni aspetti del framework di autenticazione HTTP che pongono vincoli su come possono funzionare i nuovi schemi di autenticazione:

• L'autenticazione HTTP è presunta essere stateless: tutte le informazioni necessarie per autenticare una richiesta DEVONO essere fornite nella richiesta, piuttosto che dipendere dal server che ricorda le richieste precedenti. L'autenticazione basata su, o legata a, la connessione sottostante è al di fuori dell'ambito di questa specifica e intrinsecamente difettosa a meno che non vengano presi provvedimenti per garantire che la connessione non possa essere utilizzata da nessuna parte diversa dall'utente autenticato (vedere Sezione 3.3).

• Il parametro di autenticazione "realm" è riservato per definire spazi di protezione come descritto nella Sezione 11.5. I nuovi schemi NON DEVONO utilizzarlo in modo incompatibile con quella definizione.

• La notazione "token68" è stata introdotta per compatibilità con gli schemi di autenticazione esistenti e può essere utilizzata solo una volta per challenge o credenziale. Pertanto, i nuovi schemi dovrebbero utilizzare invece la sintassi auth-param, perché altrimenti le estensioni future saranno impossibili.

• L'analisi delle challenge e delle credenziali è definita da questa specifica e non può essere modificata dai nuovi schemi di autenticazione. Quando viene utilizzata la sintassi auth-param, tutti i parametri dovrebbero supportare sia la sintassi token che quella quoted-string, e i vincoli sintattici dovrebbero essere definiti sul valore del campo dopo l'analisi (cioè, l'elaborazione della quoted-string). Questo è necessario affinché i destinatari possano utilizzare un parser generico che si applica a tutti gli schemi di autenticazione.

  Nota: Il fatto che la sintassi del valore per il parametro "realm" sia limitata a quoted-string era una cattiva scelta progettuale da non ripetere per i nuovi parametri.

• La definizione di nuovi schemi dovrebbe definire il trattamento di parametri di estensione sconosciuti. In generale, una regola "must-ignore" è preferibile a una regola "must-understand", perché altrimenti sarà difficile introdurre nuovi parametri in presenza di destinatari legacy. Inoltre, è bene descrivere la politica per la definizione di nuovi parametri (ad esempio, "aggiornare la specifica" o "utilizzare questo registro").

• Gli schemi di autenticazione devono documentare se sono utilizzabili nell'autenticazione del server di origine (cioè, utilizzando WWW-Authenticate) e/o nell'autenticazione proxy (cioè, utilizzando Proxy-Authenticate).

• Le credenziali trasportate in un campo header Authorization sono specifiche dell'user agent e, pertanto, hanno lo stesso effetto sulle cache HTTP della direttiva di risposta cache "private" ([CACHING], Sezione 5.2.2.7) nell'ambito della richiesta in cui appaiono.

  Pertanto, i nuovi schemi di autenticazione che scelgono di non trasportare le credenziali nel campo header Authorization (ad esempio, utilizzando un campo header appena definito) dovranno esplicitamente vietare la memorizzazione nella cache, imponendo l'uso di direttive di risposta cache (ad esempio, "private").

• Gli schemi che utilizzano Authentication-Info, Proxy-Authentication-Info o qualsiasi altro campo header di risposta relativo all'autenticazione devono considerare e documentare le relative considerazioni sulla sicurezza (vedere Sezione 17.16.4).

16.5. Range Unit Extensibility (Estensibilità delle unità di intervallo)

16.5.1. Range Unit Registry (Registro delle unità di intervallo)

Il "HTTP Range Unit Registry" definisce il namespace per i nomi delle unità di intervallo e fa riferimento alle relative specifiche. È mantenuto all'indirizzo https://www.iana.org/assignments/http-parameters.

La registrazione di un'unità di intervallo HTTP DEVE includere i seguenti campi:

• Name (Nome)
• Description (Descrizione)
• Pointer to specification text (Puntatore al testo di specifica)

I valori da aggiungere a questo namespace richiedono una revisione IETF (vedere [RFC8126], Sezione 4.8).

16.5.2. Considerations for New Range Units (Considerazioni per le nuove unità di intervallo)

Altre unità di intervallo, come confini specifici del formato come pagine, sezioni, record, righe o tempo, sono potenzialmente utilizzabili in HTTP per scopi specifici dell'applicazione, ma non sono comunemente utilizzate in pratica. Gli implementatori di unità di intervallo alternative dovrebbero considerare come funzionerebbero con le codifiche di contenuto e gli intermediari di uso generale.

16.6. Content Coding Extensibility (Estensibilità della codifica del contenuto)

16.6.1. Content Coding Registry (Registro della codifica del contenuto)

Il "HTTP Content Coding Registry", mantenuto da IANA all'indirizzo https://www.iana.org/assignments/http-parameters/, registra i nomi di content-coding.

Le registrazioni di codifica del contenuto DEVONO includere i seguenti campi:

• Name (Nome)
• Description (Descrizione)
• Pointer to specification text (Puntatore al testo di specifica)

I nomi delle codifiche di contenuto NON DEVONO sovrapporsi ai nomi delle codifiche di trasferimento (secondo il "HTTP Transfer Coding Registry" situato all'indirizzo https://www.iana.org/assignments/http-parameters/) a meno che la trasformazione di codifica non sia identica (come nel caso delle codifiche di compressione definite nella Sezione 8.4.1).

I valori da aggiungere a questo namespace richiedono una revisione IETF (vedere Sezione 4.8 di [RFC8126]) e DEVONO conformarsi allo scopo della codifica del contenuto definito nella Sezione 8.4.1.

16.6.2. Considerations for New Content Codings (Considerazioni per le nuove codifiche di contenuto)

Le nuove codifiche di contenuto dovrebbero essere auto-descrittive quando possibile, con parametri opzionali individuabili all'interno del formato di codifica stesso, piuttosto che fare affidamento su metadati esterni che potrebbero andare persi durante il transito.

16.7. Upgrade Token Registry (Registro dei token di aggiornamento)

Il "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" definisce il namespace per i token protocol-name utilizzati per identificare i protocolli nel campo header Upgrade. Il registro è mantenuto all'indirizzo https://www.iana.org/assignments/http-upgrade-tokens.

Ogni nome di protocollo registrato è associato a informazioni di contatto e a un set opzionale di specifiche che dettagliano come verrà elaborata la connessione dopo essere stata aggiornata.

Le registrazioni avvengono su base "First Come First Served" (vedere Sezione 4.4 di [RFC8126]) e sono soggette alle seguenti regole:

1. Un token protocol-name, una volta registrato, rimane registrato per sempre.

2. Un token protocol-name è case-insensitive e registrato con il caso preferito da generare dai mittenti.

3. La registrazione DEVE nominare una parte responsabile per la registrazione.

4. La registrazione DEVE nominare un punto di contatto.

5. La registrazione PUÒ nominare un set di specifiche associate a quel token. Tali specifiche non devono essere pubblicamente disponibili.

6. La registrazione DOVREBBE nominare un set di token "protocol-version" previsti associati a quel token al momento della registrazione.

7. La parte responsabile PUÒ modificare la registrazione in qualsiasi momento. IANA manterrà un registro di tutte tali modifiche e le renderà disponibili su richiesta.

8. IESG PUÒ riassegnare la responsabilità per un token di protocollo. Questo sarà normalmente utilizzato solo nel caso in cui una parte responsabile non possa essere contattata.