Anhang A. Hintergrund
Viele Jahre lang wurde das "X-"-Präfix für experimentelle oder Erweiterungsparameter in Anwendungsprotokollen verwendet. Beispiele umfassen:
File Transfer Protocol (FTP)
Das File Transfer Protocol (FTP) [RFC775] enthält das Konzept der "experimentellen Befehle", von denen einige mit "X" präfixiert wurden (z.B. "XSEN", "XRSQ", "XRCP"), was zur Konvention führte, dass experimentelle FTP-Befehle das "X"-Präfix verwenden sollten. Diese Konvention wurde auf andere Protokolle ausgedehnt.
Die Autoren von [RFC691] argumentierten, dass diese Konvention aus zwei Gründen unzureichend sei:
-
Ein "X"-Präfix verhindert keine Namenskollisionen, wenn zwei verschiedene Implementierungen denselben "X-"-Namen verwenden.
-
Parameter mit einem "X-"-Präfix könnten in die dauerhafte Nutzung durchsickern, und zu diesem Zeitpunkt würde das Entfernen des Präfixes Interoperabilitätsprobleme verursachen.
Trotz dieser Probleme wurde die "X-"-Präfix-Konvention zur gängigen Praxis.
E-Mail-Header
Frühe Spezifikationen für E-Mail-Header (wie [RFC822]) unterschieden zwischen "extension-fields" (die formal standardisiert waren) und "user-defined-fields" (die es nicht waren). Benutzerdefinierte Felder mussten mit "X-" beginnen. Diese Konvention setzte sich durch [RFC1123] fort und wurde in [RFC2045], [RFC2046] und [RFC2047] für MIME kodifiziert.
[RFC2822] entfernte jedoch die Unterscheidung und stellte fest, dass die "X-"-Konvention "die unglückliche Tendenz hat, Entwickler glauben zu lassen, dass [solche Felder] niemals registriert oder standardisiert werden müssen", was zu erheblichen Interoperabilitätsproblemen führte, als "X-"-Felder weit verbreitet eingesetzt wurden.
Ähnliche Änderungen traten in anderen E-Mail-bezogenen Protokollen auf. Zum Beispiel etablierte [RFC3864] einen Registrierungsmechanismus für alle E-Mail-Header-Felder, unabhängig davon, ob sie ein "X-"-Präfix haben.
HTTP-Header
Frühe HTTP-Spezifikationen ([RFC2068], später [RFC2616]) schrieben die "X-"-Konvention für Erweiterungsheader nicht vor, aber sie wurde zur gängigen Praxis. Dies führte zu Situationen, in denen weit verbreitete Header wie "X-Forwarded-For" nicht einfach standardisiert werden konnten, da das Entfernen des "X-"-Präfixes die Kompatibilität brechen würde.
vCard und iCalendar
Die vCard-Spezifikation [RFC2426] erlaubte Erweiterungstypen und -eigenschaften mit einem "X-"-Präfix. Ähnlich verwendet iCalendar [RFC5545] ein "x-name"-Konstrukt für experimentelle Eigenschaften und Parameter. Diese Spezifikationen erlauben weiterhin solche Namen, während sie auch Registrierungsmechanismen für alle Eigenschaften und Parameter bereitstellen.
URN-Namensräume
Der URN-Namensraum-Definitionsmechanismus [RFC3406] reserviert bestimmte Namensräume für experimentelle Zwecke (NID-Werte, die mit "x-" beginnen), weist aber auch darauf hin, dass solche Namen nicht in Produktionssystemen verwendet werden sollten.
LDAP-Feldnamen
LDAP [RFC4512] erlaubt Attributbeschreibungen, die mit "x-" beginnen, für private oder experimentelle Verwendung, aber solche Attribute können bei Bedarf standardisiert werden.
Schlussfolgerung
Die historischen Aufzeichnungen zeigen, dass die "X-"-Konvention zwar dazu gedacht war, Kollisionen zwischen standardisierten und nicht standardisierten Parametern zu verhindern, dieses Ziel jedoch oft nicht erreicht hat und erhebliche Migrations- und Interoperabilitätsprobleme geschaffen hat, als experimentelle Parameter weit verbreitet eingesetzt wurden.