Zum Hauptinhalt springen

2.2. Dokumentationsanforderungen für Registries

2.2. Dokumentationsanforderungen für Registries (Documentation Requirements for Registries)​

Dokumente, die einen neuen Namensraum erstellen (oder die Definition eines vorhandenen Raums ändern) und von denen erwartet wird, dass IANA eine Rolle bei der Pflege dieses Raums spielt (als Repository für registrierte Werte dient), müssen klare Anweisungen zu Details des Namensraums bereitstellen, entweder im Abschnitt IANA Considerations oder von dort referenziert.

Insbesondere müssen solche Anweisungen Folgendes enthalten:

Der Name der Registry (The name of the registry)​

Dieser Name wird auf der IANA-Webseite erscheinen und in zukünftigen Dokumenten referenziert werden, die einen Wert aus dem neuen Raum zuweisen müssen. Der vollständige Name (und die Abkürzung, falls zutreffend) sollte angegeben werden. Es ist sehr wünschenswert, dass der gewählte Name nicht leicht mit dem Namen einer anderen Registry verwechselt werden kann.

Beim Erstellen einer Registry muss die Gruppe, zu der sie gehört, unter Verwendung ihres vollständigen Namens identifiziert werden, genau so, wie er in der Protocol Registries-Liste erscheint.

Die Angabe einer URL zur genauen Identifizierung der Registry hilft IANA, die Anforderung zu verstehen. Solche URLs können vor der endgültigen Veröffentlichung aus dem RFC entfernt oder im Dokument zur Referenz belassen werden. Wenn Sie iana.org-URLs einschließen, wird IANA bei Bedarf während ihrer Überprüfung Korrekturen vornehmen.

Erforderliche Informationen für Registrierungen (Required information for registrations)​

Dies teilt Registranten mit, welche Informationen sie in ihre Registrierungsanforderungen aufnehmen müssen. Einige Registries erfordern nur den angeforderten Wert und einen Verweis auf ein Dokument, in dem die Verwendung des Werts definiert ist. Andere Registries erfordern eine detailliertere Registrierungsvorlage, die relevante Sicherheitsüberlegungen, Internationalisierungsüberlegungen und andere solche Informationen beschreibt.

Anwendbare Registrierungsrichtlinie (Applicable registration policy)​

Die Richtlinie, die für alle zukünftigen Registrierungsanforderungen gelten wird. Siehe Abschnitt 4.

Größe, Format und Syntax von Registry-Einträgen (Size, format, and syntax of registry entries)​

Welche Felder in der Registry aufzuzeichnen sind, alle technischen Anforderungen an Registry-Einträge (gültige Bereiche für Ganzzahlen, Längenbeschränkungen für Zeichenketten usw.) und das genaue Format, in dem Registry-Werte angezeigt werden sollen. Bei numerischen Zuweisungen sollte angegeben werden, ob Werte in Dezimal-, Hexadezimal- oder einem anderen Format aufgezeichnet werden sollen.

Es wird erwartet, dass Zeichenketten ASCII sind, und es sollte klar angegeben werden, ob Groß-/Kleinschreibung wichtig ist und ob beispielsweise Zeichenketten in der Registry in Groß- oder Kleinbuchstaben angezeigt werden sollen.

Zeichenketten, die Protokollparameter darstellen, müssen selten, wenn überhaupt, Nicht-ASCII-Zeichen enthalten. Wenn Nicht-ASCII-Zeichen wirklich notwendig sind, sollten die Anweisungen sehr klar machen, dass sie erlaubt sind und dass die Nicht-ASCII-Zeichen als Unicode-Zeichen unter Verwendung der "(U+XXXX)"-Konvention dargestellt werden sollten. Jeder, der eine solche Registry erstellt, sollte dies sorgfältig überdenken und Internationalisierungsratschläge wie die in [RFC7564], Abschnitt 10, in Betracht ziehen.

Anfängliche Zuweisungen und Reservierungen (Initial assignments and reservations)​

Alle anfänglichen Zuweisungen oder Registrierungen, die einbezogen werden sollen. Darüber hinaus sollten alle Bereiche angegeben werden, die für "Private Use", "Reserved", "Unassigned" usw. reserviert werden sollen (siehe Abschnitt 6).

Beispielsweise könnte ein Dokument eine neue Registry angeben, indem es Folgendes enthält:

---------------------------------------------------------------

X. IANA-Überlegungen

Dieses Dokument definiert eine neue DHCP-Option mit dem Titel "FooBar" (siehe
Abschnitt y) und weist einen Wert von TBD1 aus dem DHCP-Optionsraum zu
<https://www.iana.org/assignments/bootp-dhcp-parameters>
[RFC2132] [RFC2939]:
                                Data
       Tag     Name            Length      Meaning
       ----    ----            ------      -------
       TBD1    FooBar          N           FooBar-Server

Die FooBar-Option definiert auch ein 8-Bit-FooType-Feld, für das
IANA eine neue Registry mit dem Titel "FooType values" erstellen und pflegen soll,
die von der FooBar-Option verwendet wird. Anfangswerte für die
DHCP FooBar FooType-Registry sind unten angegeben; zukünftige Zuweisungen
sollen durch Expert Review [BCP26] erfolgen. Zuweisungen bestehen
aus einem DHCP FooBar FooType-Namen und seinem zugehörigen Wert.

       Value    DHCP FooBar FooType Name   Definition
       ----     ------------------------   ----------
       0        Reserved
       1        Frobnitz                   RFCXXXX, Abschnitt y.1
       2        NitzFrob                   RFCXXXX, Abschnitt y.2
       3-254    Unassigned
       255      Reserved
---------------------------------------------------------------

Beispiele für Dokumente, die Registries einrichten, finden Sie in [RFC3575], [RFC3968] und [RFC4520].

Jedes Mal, wenn IANA Namen und Kontaktinformationen in die öffentliche Registry aufnimmt, könnten einige Personen es vorziehen, dass ihre Kontaktinformationen nicht öffentlich gemacht werden. In solchen Fällen können Vereinbarungen mit IANA getroffen werden, um die Kontaktinformationen privat zu halten.

Letztes Update am