1. Introduzione

Molti protocolli applicativi utilizzano parametri con nomi testuali (in contrapposizione ai nomi numerici) per identificare i dati (tipi di media, campi di intestazione nei messaggi di posta Internet e nelle richieste HTTP, parametri e proprietà vCard, ecc.). Storicamente, i progettisti e gli implementatori di protocolli applicativi hanno spesso distinto tra parametri standardizzati e non standardizzati prefissando i nomi dei parametri non standardizzati con la stringa "X-" o costrutti simili (ad esempio, "x."), dove la "X" è comunemente intesa come "sperimentale (eXperimental)" o "estensione (eXtension)".

Secondo questa convenzione, il nome di un parametro non solo identificava i dati, ma incorporava anche lo stato del parametro nel nome stesso: un parametro definito in una specifica prodotta da un'organizzazione di sviluppo di standard riconosciuta (o registrato secondo i processi definiti in tale specifica) non iniziava con "X-" o costrutti simili, mentre un parametro definito al di fuori di tale specifica o processo iniziava con "X-" o costrutti simili.

Come spiegato più dettagliatamente nell'Appendice A, questa convenzione è stata incoraggiata per molti anni in protocolli applicativi come il trasferimento di file, la posta elettronica e il World Wide Web. In particolare, è stata codificata per la posta elettronica da [RFC822] (tramite la distinzione tra "Extension-fields" e "user-defined-fields"), ma poi rimossa da [RFC2822] sulla base dell'esperienza di implementazione e distribuzione. Una progressione simile si è verificata per le tecnologie SIP per quanto riguarda l'intestazione "P-", come spiegato in [RFC5727]. Il ragionamento alla base di questi cambiamenti è esplorato nell'Appendice B.

In breve, sebbene in teoria la convenzione "X-" fosse un buon modo per evitare collisioni (e i relativi problemi di interoperabilità) tra parametri standardizzati e non standardizzati, in pratica i benefici sono stati superati dai costi associati alla fuoriuscita di parametri non standardizzati nello spazio degli standard.

Questo documento generalizza dall'esperienza delle comunità di posta elettronica e SIP facendo quanto segue:

1. Depreca la convenzione "X-" per i parametri di nuova definizione nei protocolli applicativi, compresi i nuovi parametri per i protocolli consolidati. Questa modifica si applica anche dove la convenzione "X-" era solo implicita e non fornita esplicitamente, come è stato fatto per la posta elettronica in [RFC822].

2. Formula raccomandazioni specifiche su come procedere in un mondo senza la distinzione tra parametri standardizzati e non standardizzati (sebbene solo per i parametri con nomi testuali, non per i parametri espressi come numeri, che sono fuori dall'ambito di questo documento).

3. Non raccomanda contro la pratica di parametri privati, locali, preliminari, sperimentali o specifici dell'implementazione, solo contro l'uso di "X-" e costrutti simili nei nomi di tali parametri.

4. Non formula raccomandazioni sul fatto che i parametri "X-" esistenti debbano rimanere in uso o essere migrati a un formato senza "X-"; questa è una questione per i creatori o i manutentori di tali parametri.

5. Non sostituisce le specifiche esistenti che legiferano l'uso di "X-" per particolari protocolli applicativi (ad esempio, il token "x-name" in [RFC5545]); questa è una questione per i progettisti di tali protocolli.

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 in [RFC2119].