4.6. Specification Required
4.6. Specification Required
Bei der Richtlinie Specification Required sind Prüfung und Genehmigung durch einen designated expert (siehe Abschnitt 5) erforderlich, und die Werte sowie ihre Bedeutungen müssen in einer dauerhaften und leicht verfügbaren öffentlichen Spezifikation so detailliert dokumentiert sein, dass Interoperabilität zwischen unabhängigen Implementierungen möglich ist. Diese Richtlinie entspricht Expert Review, ergänzt um die Anforderung einer formalen öffentlichen Spezifikation. Zusätzlich zur normalen Prüfung eines solchen Antrags prüft der designated expert die öffentliche Spezifikation und bewertet, ob sie ausreichend stabil und dauerhaft sowie ausreichend klar und technisch solide ist, um interoperable Implementierungen zu ermöglichen.
Die Absicht hinter "dauerhaft und leicht verfügbar" ist, dass vernünftigerweise erwartet werden kann, dass ein Dokument noch lange nach der IANA-Zuweisung des angeforderten Werts auffindbar und abrufbar ist. Die Veröffentlichung eines RFC ist ein ideales Mittel, um diese Anforderung zu erfüllen, aber Specification Required soll auch den Fall abdecken, dass ein Dokument außerhalb des RFC-Pfads veröffentlicht wird, einschließlich informeller Dokumentation.
Für eine RFC-Veröffentlichung wird weiterhin eine formale Prüfung durch den designated expert verlangt, aber der normale RFC-Prüfprozess soll die notwendige Prüfung der Interoperabilität liefern. Die Prüfung durch den designated expert bleibt wichtig; ebenso wichtig ist jedoch der Hinweis, dass der Experte bei IETF-Konsens manchmal "in the rough" sein kann (siehe auch den letzten Absatz von Abschnitt 5.4).
Wie bei Expert Review (Abschnitt 4.5) sollte bei der Definition des Registers eine klare Anleitung für den designated expert bereitgestellt werden, und ein gründliches Verständnis von Abschnitt 5 ist wichtig.
Bei der Angabe dieser Richtlinie sollte einfach der Begriff "Specification Required" verwendet werden. Einige Spezifikationen haben sie als "Expert Review with Specification Required" bezeichnet, was nur Verwirrung verursacht.
Beispiele:
- Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124]
- TLS ClientCertificateType Identifiers 64-223 [RFC5246]
- ROHC Profile Identifiers [RFC5795]