1. Einleitung (Introduction)

URIs [RFC3986] enthalten sehr oft strukturierte Anwendungsdaten. Dies kann Artefakte aus Dateisystemen (die häufig in der Pfadkomponente auftreten) und Benutzerinformationen (häufig in der Abfragekomponente) umfassen. In einigen Fällen können sich sogar anwendungsspezifische Daten in der Autoritätskomponente befinden (z. B. sind einige Anwendungen über mehrere Hostnamen verteilt, um eine Form der Partitionierung oder Verteilung zu ermöglichen).

Implementierungen können weitere Einschränkungen für die Struktur von URIs auferlegen; beispielsweise verwenden viele Webserver die Dateierweiterung des letzten Pfadsegments, um den Medientyp der Antwort zu bestimmen. Ebenso haben verpackte Anwendungen oft hochstrukturierte URIs, die nur in begrenztem Maße geändert werden können (oft nur der Hostname und der Port, auf dem sie bereitgestellt werden).

Da der Eigentümer des URI (wie in [webarch], Abschnitt 2.2.2.1 definiert) sich entscheidet, den Server oder die Anwendung zu verwenden, kann dies als angemessene Delegation von Autorität angesehen werden. Wenn solche Konventionen jedoch von einer anderen Partei als dem Eigentümer vorgeschrieben werden, kann dies mehrere potenziell schädliche Auswirkungen haben:

• Kollisionen (Collisions) - Je mehr Ad-hoc-Konventionen für URI-Strukturen standardisiert werden, desto wahrscheinlicher wird es, dass es zu Kollisionen zwischen ihnen kommt (insbesondere in Anbetracht dessen, dass Server, Anwendungen und einzelne Bereitstellungen ihre eigenen Konventionen haben werden).

• Verdünnung (Dilution) - Wenn die einem URI hinzugefügten Informationen ephemer sind, verdünnt dies seinen Nutzen, indem seine Stabilität verringert wird (siehe [webarch], Abschnitt 3.5.1), und kann dazu führen, dass mehrere alternative Formen des URI existieren (siehe [webarch], Abschnitt 2.3.1).

• Starrheit (Rigidity) - Feste URI-Syntax behindert oft gewünschte Bereitstellungsmuster. Wenn beispielsweise eine Autorität mehrere Anwendungen auf einem einzigen Hostnamen anbieten möchte, wird dies schwierig bis unmöglich, wenn deren URIs die erforderliche Flexibilität nicht zulassen.

• Betriebliche Schwierigkeiten (Operational Difficulty) - Die Unterstützung einiger URI-Konventionen kann in einigen Implementierungen schwierig sein. Beispielsweise kann die Angabe, dass ein bestimmter Abfrageparameter mit "http"-URIs verwendet werden muss, die Verwendung von Webservern ausschließen, die die Antwort aus einem Dateisystem bereitstellen. Ebenso macht eine Anwendung, die einen Basispfad für ihren Betrieb festlegt (z. B. "/v1"), es unmöglich, andere Anwendungen mit demselben Präfix auf demselben Host bereitzustellen.

• Client-Annahmen (Client Assumptions) - Wenn Konventionen standardisiert werden, werden einige Clients unweigerlich annehmen, dass die Standards verwendet werden, wenn diese Konventionen gesehen werden. Dies kann zu Interoperabilitätsproblemen führen; wenn beispielsweise eine Spezifikation dokumentiert, dass der "sig"-URI-Abfrageparameter anzeigt, dass seine Payload eine kryptografische Signatur für den URI ist, kann dies zu unerwünschtem Verhalten führen.

Daher ist die Veröffentlichung eines Standards, der eine bestehende URI-Struktur auf eine Weise einschränkt, die nicht ausdrücklich von [RFC3986] erlaubt ist (normalerweise durch Aktualisierung der URI-Schemadefinition), manchmal problematisch, sowohl aus diesen Gründen als auch weil die Struktur eines URI fest unter der Kontrolle seines Eigentümers stehen muss.

Dieses Dokument erläutert einige Best Current Practices für die Etablierung von URI-Strukturen, Konventionen und Formaten in Standards. Es bietet auch Strategien für Spezifikationen in Abschnitt 3.

1.1. Zielgruppe (Intended Audience)

Die Richtlinien und Anforderungen dieses Dokuments richten sich an die Autoren von Spezifikationen, die die Syntax oder Struktur von URIs oder deren Teilen einschränken. Zwei Klassen solcher Spezifikationen werden speziell hervorgehoben:

• Protokollerweiterungen ("Extensions") - Spezifikationen, die neue Fähigkeiten bieten, die auf jeden Bezeichner oder eine große Teilmenge möglicher Bezeichner angewendet werden könnten, z. B. einen neuen Signaturmechanismus für "http"-URIs, Metadaten für jeden URI oder ein neues Format.

• Anwendungen, die URIs verwenden ("Applications") - Spezifikationen, die URIs verwenden, um spezifische Bedürfnisse zu erfüllen, z. B. eine HTTP-Schnittstelle zu bestimmten Informationen auf einem Host.

Anforderungen, die auf die allgemeine Klasse "Spezifikationen" abzielen, gelten für alle Spezifikationen, einschließlich der oben aufgeführten und anderer.

Beachten Sie, dass diese Spezifikation nicht so interpretiert werden sollte (SHOULD NOT), dass sie die Zuweisung der Kontrolle über URIs durch Parteien verhindert, die sie rechtmäßig besitzen oder denen dieses Eigentum delegiert wurde; beispielsweise kann eine Spezifikation rechtmäßig die Semantik eines URI auf der IANA-Website als Teil der Einrichtung eines Registers definieren.

Es kann bestehende IETF-Spezifikationen geben, die bereits von den Richtlinien in diesem Dokument abweichen. In diesen Fällen liegt es an den relevanten Communities (d. h. denen des URI-Schemas sowie jeder relevanten Community, die die betreffende Spezifikation erstellt hat), ein angemessenes Ergebnis zu bestimmen, z. B. Aktualisierung der Schemadefinition oder Änderung der Spezifikation.

1.2. Notationskonventionen (Notational Conventions)

Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (muss), "SHALL NOT" (darf nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "NOT RECOMMENDED" (nicht empfohlen), "MAY" (kann) und "OPTIONAL" (optional) in diesem Dokument sind zu interpretieren wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.