Appendice B. Analisi

Problemi con la convenzione "X-"

Il problema principale con la convenzione "X-" è che i parametri non standardizzati hanno la tendenza a trapelare nello spazio protetto dei parametri standardizzati, causando così problemi di interoperabilità.

Consideriamo l'esempio dei campi di intestazione della posta elettronica. Originariamente, [RFC822] distingueva tra "Extension-fields" standardizzati e "user-defined-fields" non standardizzati, con questi ultimi che dovevano utilizzare il prefisso "X-". Tuttavia, come notato in [RFC2822], questa distinzione è stata rimossa perché:

1. Molti campi "X-" sono diventati così ampiamente distribuiti da diventare standard de facto (ad esempio, "X-Mailer").

2. Il prefisso "X-" scoraggiava gli sviluppatori dal registrare correttamente i loro campi.

3. Quando gli sviluppatori volevano standardizzare un campo "X-", si trovavano di fronte a un dilemma: mantenere il prefisso "X-" (che suggerisce erroneamente che non è standardizzato) o rimuoverlo (il che compromette la compatibilità con le implementazioni esistenti).

4. Alcuni implementatori credevano erroneamente che qualsiasi campo senza prefisso "X-" fosse formalmente standardizzato, portando a problemi di interoperabilità.

Problemi simili si sono verificati in altri protocolli:

• HTTP: Intestazioni come "X-Forwarded-For" sono diventate ampiamente distribuite ma difficili da standardizzare a causa del prefisso.

• SIP: Il prefisso "P-" per le intestazioni private (destinate alle reti chiuse) è trapelato nell'Internet più ampio, come documentato in [RFC5727].

• Tipi di media: Il prefisso "x-" per i tipi di media sperimentali ha portato agli stessi problemi, come documentato in [RFC4288].

Quando la segregazione potrebbe essere giustificata

In alcune situazioni, la segregazione dello spazio dei nomi dei parametri utilizzato in un dato protocollo applicativo può essere giustificata:

1. Quando è estremamente improbabile che alcuni parametri vengano mai standardizzati. In questo caso, i parametri specifici dell'implementazione e per uso privato potrebbero almeno incorporare il nome dell'organizzazione (ad esempio, "ExampleInc-foo" o, coerentemente con [RFC4288], "VND.ExampleInc.foo") o il nome di dominio primario (ad esempio, "com.example.foo" o un Uniform Resource Identifier [RFC3986] come "http://example.com/foo"). In rari casi, parametri veramente sperimentali potrebbero ricevere nomi privi di significato come parole senza senso, l'output di una funzione hash o Identificatori Universalmente Unici (UUID) [RFC4122].

2. Quando i nomi dei parametri potrebbero avere un significato significativo. Anche questo caso è raro, poiché gli implementatori possono quasi sempre trovare un sinonimo per un termine esistente (ad esempio, "urgency" invece di "priority") o semplicemente inventare un nome più creativo (ad esempio, "get-it-there-fast"). L'esistenza di più parametri con nomi simili può essere confusa, ma questo è vero indipendentemente dal tentativo di segregare i parametri standardizzati e non standardizzati (ad esempio, "X-Priority" può essere confuso con "Urgency").

3. Quando i nomi dei parametri devono essere molto brevi (ad esempio, come in [RFC5646] per i tag linguistici). In questo caso, può essere più efficiente assegnare numeri invece di nomi leggibili dall'uomo (ad esempio, come in [RFC2939] per le opzioni DHCP) e lasciare un certo intervallo numerico per estensioni specifiche dell'implementazione o uso privato (ad esempio, come con i numeri di codec utilizzati con il Session Description Protocol [RFC4566]).

Obiezioni alla deprecazione della convenzione "X-"

Ci sono tre obiezioni principali alla deprecazione della convenzione "X-" come best practice per i protocolli applicativi:

1. Gli implementatori potrebbero confondere un parametro con un altro parametro che ha un nome simile; una distinzione rigida come un prefisso "X-" può rendere ciò chiaro. Tuttavia, in pratica, gli implementatori sono costretti a sfumare la distinzione (ad esempio, trattando "X-foo" come uno standard de facto), quindi diventa inevitabilmente priva di significato.

2. Le collisioni sono indesiderabili, e sarebbe negativo che sia un parametro standardizzato "foo" che un parametro non standardizzato "foo" esistessero simultaneamente. Tuttavia, i nomi sono quasi sempre economici, quindi un nome sperimentale, specifico dell'implementazione o per uso privato "foo" non impedisce a un'organizzazione di sviluppo di standard di emettere un nome altrettanto creativo come "bar".

3. [BCP82] è intitolato "Assigning Experimental and Testing Numbers Considered Useful" e quindi implica che il prefisso "X-" sia anche utile per i parametri sperimentali. Tuttavia, BCP 82 affronta la necessità di numeri di protocollo quando il pool di tali numeri è strettamente limitato (ad esempio, opzioni DHCP) o quando un numero è assolutamente richiesto anche per scopi puramente sperimentali (ad esempio, il campo Protocol dell'intestazione IP). In quasi tutti i protocolli applicativi che utilizzano parametri di protocollo (incluse intestazioni di posta elettronica, tipi di media, intestazioni HTTP, parametri e proprietà vCard, URN e nomi di campi LDAP), lo spazio dei nomi non è limitato o vincolato in alcun modo, quindi non c'è bisogno di assegnare un blocco di nomi per uso privato o scopi sperimentali (vedere anche [BCP26]).

Conclusione

Pertanto, sembra che la segregazione dello spazio dei parametri in un'area standardizzata e un'area non standardizzata abbia pochi, se non nessuno, benefici e abbia almeno un costo significativo in termini di interoperabilità.