1. Einleitung

Viele Anwendungsprotokolle verwenden Parameter mit textuellen (im Gegensatz zu numerischen) Namen zur Identifizierung von Daten (Medientypen, Header-Felder in Internet-Mail-Nachrichten und HTTP-Anfragen, vCard-Parameter und -Eigenschaften usw.). Historisch gesehen haben Entwickler und Implementierer von Anwendungsprotokollen häufig zwischen standardisierten und nicht standardisierten Parametern unterschieden, indem sie den Namen nicht standardisierter Parameter mit der Zeichenkette "X-" oder ähnlichen Konstrukten (z.B. "x.") voranstellten, wobei das "X" allgemein als "eXperimentell" oder "eXtension" verstanden wird.

Nach dieser Konvention identifizierte der Name eines Parameters nicht nur die Daten, sondern bettete auch den Status des Parameters in den Namen selbst ein: Ein Parameter, der in einer von einer anerkannten Standardisierungsorganisation erstellten Spezifikation definiert wurde (oder gemäß in einer solchen Spezifikation definierten Prozessen registriert wurde), begann nicht mit "X-" oder ähnlichen Konstrukten, während ein Parameter, der außerhalb einer solchen Spezifikation oder eines solchen Prozesses definiert wurde, mit "X-" oder ähnlichen Konstrukten begann.

Wie in Anhang A ausführlicher erläutert, wurde diese Konvention viele Jahre lang in Anwendungsprotokollen wie Dateiübertragung, E-Mail und dem World Wide Web gefördert. Insbesondere wurde sie für E-Mail durch [RFC822] kodifiziert (über die Unterscheidung zwischen "Extension-fields" und "user-defined-fields"), dann aber aufgrund von Implementierungs- und Bereitstellungserfahrungen durch [RFC2822] entfernt. Eine ähnliche Entwicklung fand bei SIP-Technologien bezüglich des "P-"-Headers statt, wie in [RFC5727] erläutert. Die Überlegungen hinter diesen Änderungen werden in Anhang B untersucht.

Kurz gesagt, obwohl die "X-"-Konvention theoretisch ein guter Weg war, Kollisionen (und damit verbundene Interoperabilitätsprobleme) zwischen standardisierten und nicht standardisierten Parametern zu vermeiden, haben in der Praxis die Vorteile nicht die Kosten aufgewogen, die mit dem Durchsickern nicht standardisierter Parameter in den Standardraum verbunden sind.

Dieses Dokument verallgemeinert die Erfahrungen der E-Mail- und SIP-Gemeinschaften, indem es Folgendes tut:

1. Schafft die "X-"-Konvention für neu definierte Parameter in Anwendungsprotokollen ab, einschließlich neuer Parameter für etablierte Protokolle. Diese Änderung gilt auch dort, wo die "X-"-Konvention nur implizit und nicht explizit vorgesehen war, wie es für E-Mail in [RFC822] geschehen ist.

2. Gibt spezifische Empfehlungen darüber, wie in einer Welt ohne Unterscheidung zwischen standardisierten und nicht standardisierten Parametern vorzugehen ist (allerdings nur für Parameter mit textuellen Namen, nicht für Parameter, die als Zahlen ausgedrückt werden, die außerhalb des Anwendungsbereichs dieses Dokuments liegen).

3. Empfiehlt nicht gegen die Praxis privater, lokaler, vorläufiger, experimenteller oder implementierungsspezifischer Parameter, nur gegen die Verwendung von "X-" und ähnlichen Konstrukten in den Namen solcher Parameter.

4. Gibt keine Empfehlung ab, ob bestehende "X-"-Parameter weiterhin verwendet oder in ein Format ohne "X-" migriert werden sollten; dies ist eine Angelegenheit für die Ersteller oder Betreuer dieser Parameter.

5. Überschreibt nicht bestehende Spezifikationen, die die Verwendung von "X-" für bestimmte Anwendungsprotokolle vorschreiben (z.B. das "x-name"-Token in [RFC5545]); dies ist eine Angelegenheit für die Entwickler dieser Protokolle.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.