Zum Hauptinhalt springen

Anhang B. Analyse

Probleme mit der "X-"-Konvention​

Das Hauptproblem mit der "X-"-Konvention besteht darin, dass nicht standardisierte Parameter dazu neigen, in den geschützten Raum standardisierter Parameter durchzusickern und dadurch Interoperabilitätsprobleme zu verursachen.

Betrachten Sie das Beispiel der E-Mail-Header-Felder. Ursprünglich unterschied [RFC822] zwischen standardisierten "Extension-fields" und nicht standardisierten "user-defined-fields", wobei letztere das "X-"-Präfix verwenden mussten. Wie jedoch in [RFC2822] vermerkt, wurde diese Unterscheidung aus folgenden Gründen entfernt:

  1. Viele "X-"-Felder wurden so weit verbreitet eingesetzt, dass sie zu De-facto-Standards wurden (z.B. "X-Mailer").

  2. Das "X-"-Präfix hielt Entwickler davon ab, ihre Felder ordnungsgemäß zu registrieren.

  3. Als Entwickler ein "X-"-Feld standardisieren wollten, standen sie vor einem Dilemma: das "X-"-Präfix beibehalten (was fälschlicherweise darauf hindeutet, dass es nicht standardisiert ist) oder es entfernen (was die Kompatibilität mit bestehenden Implementierungen bricht).

  4. Einige Implementierer glaubten fälschlicherweise, dass jedes Feld ohne "X-"-Präfix formal standardisiert sei, was zu Interoperabilitätsproblemen führte.

Ähnliche Probleme traten in anderen Protokollen auf:

  • HTTP: Header wie "X-Forwarded-For" wurden weit verbreitet eingesetzt, waren aber aufgrund des Präfixes schwer zu standardisieren.

  • SIP: Das "P-"-Präfix für private Header (für geschlossene Netzwerke bestimmt) sickerte in das breitere Internet durch, wie in [RFC5727] dokumentiert.

  • Medientypen: Das "x-"-Präfix für experimentelle Medientypen führte zu denselben Problemen, wie in [RFC4288] dokumentiert.

Wann Segregation gerechtfertigt sein könnte​

In einigen Situationen kann die Segregation des in einem bestimmten Anwendungsprotokoll verwendeten Parameternamensraums gerechtfertigt sein:

  1. Wenn es äußerst unwahrscheinlich ist, dass einige Parameter jemals standardisiert werden. In diesem Fall könnten implementierungsspezifische und private Parameter zumindest den Organisationsnamen (z.B. "ExampleInc-foo" oder, konsistent mit [RFC4288], "VND.ExampleInc.foo") oder den primären Domainnamen (z.B. "com.example.foo" oder einen Uniform Resource Identifier [RFC3986] wie "http://example.com/foo") einbeziehen. In seltenen Fällen könnten wirklich experimentelle Parameter bedeutungslose Namen erhalten, wie Nonsens-Wörter, die Ausgabe einer Hash-Funktion oder Universally Unique Identifiers (UUIDs) [RFC4122].

  2. Wenn Parameternamen eine erhebliche Bedeutung haben könnten. Auch dieser Fall ist selten, da Implementierer fast immer ein Synonym für einen bestehenden Begriff finden (z.B. "urgency" statt "priority") oder einfach einen kreativeren Namen erfinden können (z.B. "get-it-there-fast"). Die Existenz mehrerer ähnlich benannter Parameter kann verwirrend sein, aber dies gilt unabhängig davon, ob versucht wird, standardisierte und nicht standardisierte Parameter zu trennen (z.B. kann "X-Priority" mit "Urgency" verwechselt werden).

  3. Wenn Parameternamen sehr kurz sein müssen (z.B. wie in [RFC5646] für Sprach-Tags). In diesem Fall kann es effizienter sein, Zahlen anstelle von menschenlesbaren Namen zuzuweisen (z.B. wie in [RFC2939] für DHCP-Optionen) und einen bestimmten numerischen Bereich für implementierungsspezifische Erweiterungen oder private Nutzung zu reservieren (z.B. wie bei den Codec-Nummern, die mit dem Session Description Protocol [RFC4566] verwendet werden).

Einwände gegen die Abschaffung der "X-"-Konvention​

Es gibt drei Haupteinwände gegen die Abschaffung der "X-"-Konvention als Best Practice für Anwendungsprotokolle:

  1. Implementierer könnten einen Parameter mit einem anderen Parameter verwechseln, der einen ähnlichen Namen hat; eine strikte Unterscheidung wie ein "X-"-Präfix kann dies klarstellen. In der Praxis sind Implementierer jedoch gezwungen, die Unterscheidung zu verwischen (z.B. indem sie "X-foo" als De-facto-Standard behandeln), sodass sie unweigerlich bedeutungslos wird.

  2. Kollisionen sind unerwünscht, und es wäre schlecht, wenn sowohl ein standardisierter Parameter "foo" als auch ein nicht standardisierter Parameter "foo" gleichzeitig existieren würden. Namen sind jedoch fast immer billig, sodass ein experimenteller, implementierungsspezifischer oder privat genutzter Name "foo" eine Standardisierungsorganisation nicht daran hindert, einen ähnlich kreativen Namen wie "bar" zu vergeben.

  3. [BCP82] trägt den Titel "Assigning Experimental and Testing Numbers Considered Useful" und impliziert daher, dass das "X-"-Präfix auch für experimentelle Parameter nützlich ist. BCP 82 behandelt jedoch den Bedarf an Protokollnummern, wenn der Pool solcher Nummern streng begrenzt ist (z.B. DHCP-Optionen) oder wenn eine Nummer selbst für rein experimentelle Zwecke absolut erforderlich ist (z.B. das Protocol-Feld des IP-Headers). In fast allen Anwendungsprotokollen, die Protokollparameter verwenden (einschließlich E-Mail-Header, Medientypen, HTTP-Header, vCard-Parameter und -Eigenschaften, URNs und LDAP-Feldnamen), ist der Namensraum in keiner Weise begrenzt oder eingeschränkt, sodass es nicht notwendig ist, einen Block von Namen für private Nutzung oder experimentelle Zwecke zuzuweisen (siehe auch [BCP26]).

Schlussfolgerung​

Daher scheint es, dass die Segregation des Parameterraums in einen standardisierten und einen nicht standardisierten Bereich wenige oder keine Vorteile hat und mindestens einen erheblichen Kostenfaktor in Bezug auf Interoperabilität aufweist.

Letztes Update am